From nobody Sat Nov 18 10:46:40 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 3E38C126D46 for ; Sat, 18 Nov 2017 10:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3s8nzd-4y4Mo for ; Sat, 18 Nov 2017 10:46:37 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E34A126B6E for ; Sat, 18 Nov 2017 10:46:37 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id e10so3520994uah.10 for ; Sat, 18 Nov 2017 10:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SXK3V2sht+0na2psrxGq8sVeXl3nreWFu+LwLH3mEeU=; b=trH7Ob+0Yb5C0s8Vc+6+1WOSFr4fRcVOhId+t4k6+fbWmbXOHuznnttGWb1h+z0+5k HCJ5f4G5zSC4Gmli76U2Ho0lSISm9PkXmKCIO5rc+t8IyTk2PmLCyW7qrNAjYL282ouE VNsmkfpS7VqLedIwXQT6ATrGXEtjBZY/7nsXJQbKPZsFQuyxq9JyXIRKqWyUIbKTnmWy rULVCHQbwMSuBKY0/0fIKbB5M0Yduhz1BcWt5hf3ob/2SwKLnNBk25p6/IlwVLIT09Pm yzri6RCd4kZRmTvcm5ULoTHfa4RY4QWIJUAfqJEKG3maNPgC3uFRLSN/CARicPpanrpc wwkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SXK3V2sht+0na2psrxGq8sVeXl3nreWFu+LwLH3mEeU=; b=W2E84IvbJ5rW4GBo4Kt6mQnK+NLH+ju620TwV+imMxIZMxHroSf3HIs7UbsbC7FkVX z8UtEGRthH+t2e0OliLjTkrMRr6tUTgGcyRqRjoBPT8iGPINbIq8ALh8iRXDQ1dMufCV TiclIOGXwXgV9hKRZHXA62aV5IHN0HkJEIStumBLeHxKC2GA5hJ/C4R1NqRatNjjuKQm 0ITB1s5cQMYeXOhuOxuq21Ph8hgMGPc9iDBnVs96WpUPNCJh5aJEvNHjHwlw7oGF7/mQ fzfDZb4rK5/M0CEgE0qFsVfU2rdu+Ue+i+vSumid0i3Sno596jZFZKnVcaotOxR5l4Pg FDWw== X-Gm-Message-State: AJaThX4l4T5b0tgkDX7X69aRb/cvNOjBtxsbRRTG0xhthYk8CQfBr+2x Yoks211PSGweiE7rQJuqSLvJFHh+erYzKHT4Fn2WvaAi X-Google-Smtp-Source: AGs4zMYdy0An3hbssFTMXwFRP9cCc3ej0huzvMvexoeUyQoXdN0gFBqFtGWPDJztuDajtEsetUns7UoZanzwggDdc+c= X-Received: by 10.176.71.226 with SMTP id w34mr8536860uac.33.1511030795933; Sat, 18 Nov 2017 10:46:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Sat, 18 Nov 2017 10:46:15 -0800 (PST) From: Bernard Aboba Date: Sat, 18 Nov 2017 10:46:15 -0800 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary="f40304379198d61e7a055e4645cc" Archived-At: Subject: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language 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: Sat, 18 Nov 2017 18:46:39 -0000 --f40304379198d61e7a055e4645cc Content-Type: text/plain; charset="UTF-8" At this point, only a single Issue (43) remains open on draft-ietf-slim-negotiating-human-language:: https://trac.ietf.org/trac/slim/ticket/43 This relates to the modality of a language indication. Currently, Gunnar has suggested a modification to the text of Section 5.4 in order to address the issue: https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g Can WG participants review this suggested change, so that we can determine how to move forward? Currently, Section 5.4 states that: The problem of knowing which language tags are signed and which are not is out of scope of this document. --f40304379198d61e7a055e4645cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At this point, only a single Issue (43) remains open on dr= aft-ietf-slim-negotiating-human-language::=C2=A0




Can WG pa= rticipants review this suggested change, so that we can determine how to mo= ve forward?=C2=A0

Currently, Section 5.4 states th= at:=C2=A0

   The problem of knowing which language =
tags are signed and which are
   not is out of scope of this document.
--f40304379198d61e7a055e4645cc-- From nobody Sat Nov 18 14:33:30 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 6ECA1126579 for ; Sat, 18 Nov 2017 14:33:29 -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 d67nea0sqJJn for ; Sat, 18 Nov 2017 14:33:27 -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 DCE051200F3 for ; Sat, 18 Nov 2017 14:33:26 -0800 (PST) X-Halon-ID: 72de605f-ccb0-11e7-96ac-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 72de605f-ccb0-11e7-96ac-005056917f90; Sat, 18 Nov 2017 23:33:07 +0100 (CET) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se> Date: Sat, 18 Nov 2017 23:33:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C4002CE67E9F13948F009B01" Content-Language: en-US Archived-At: Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language 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: Sat, 18 Nov 2017 22:33:29 -0000 This is a multi-part message in MIME format. --------------C4002CE67E9F13948F009B01 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Bernard for pushing for closing the last open issue. Den 2017-11-18 kl. 19:46, skrev Bernard Aboba: > At this point, only a single Issue (43) remains open on > draft-ietf-slim-negotiating-human-language:: > https://trac.ietf.org/trac/slim/ticket/43 > > This relates to the modality of a language indication. > > Currently, Gunnar has suggested a modification to the text of Section > 5.4 in order to address the issue: > https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g > > > Can WG participants review this suggested change, so that we can > determine how to move forward? > > Currently, Section 5.4 states that: > > The problem of knowing which language tags are signed and which are > not is out of scope of this document. I earlier thought that an application needed to look into the language subtag Description to find the word "sign" there in the text string. That is not a good solution. But when studying the topic again in RFC 5646 I found that there is a consistent machine-implementable way to assess if a language subtag is for a sign language. Therefore I included this text in the latest proposal for section 5.4 at the link that Bernard provided: " A specific sign language can be identified by its existence in the IANA registry of language subtags according to BCP 47 [RFC5646] , and finding that the language subtag is found at least in two entries in the registry, once with the Type field "language" and once with the Type field "extlang" combined with the Prefix field value "sgn". " So that should be the response on Dales request to easily decide if a language tag is for a sign language. Worse is next topic in issue 43: to assess if a language tag is for a spoken modality or written modality of a language. My wording proposal starts with the obvious cases: a non-signed languge tag in audio media is spoken, and a non-signed language tag in text media is written.  But for other cases, like in video or message or application or multiplexed media, other indications must be used to understand the intended modality. The proposed text mentions a few, and leaves to applications to decide which mechanisms to use for such cases. I wish we for the ambiguous cases could use the script subtag -zxxx to indicate spoken modality and a real script subtag even on language subtags where script subtags are suppressed, because that would satisfy issue 43 nicely and make section 5.4 much shorter and clearer. But we have had resistance against that solution. The proposed text might be a bit long and detailed. I am prepared to agree on a shortened version if there are any proposals. I think though that contents of 5.4 in the direction of my proposal is what satisfies  issue 43 and also the comments lately that section 5.4 is too restrictive. /Gunnar > > > _______________________________________________ > 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 --------------C4002CE67E9F13948F009B01 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Bernard for pushing for closing the last open issue.
Den 2017-11-18 kl. 19:46, skrev Bernard Aboba:
At this point, only a single Issue (43) remains open on draft-ietf-slim-negotiating-human-language:: 

This relates to the modality of a language indication. 

Currently, Gunnar has suggested a modification to the text of Section 5.4 in order to address the issue: 


Can WG participants review this suggested change, so that we can determine how to move forward? 

Currently, Section 5.4 states that: 

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.
I earlier thought that an application needed to look into the language subtag Description to find the word "sign" there in the text string. That is not a good solution. But when studying the topic again in RFC 5646 I found that there is a consistent machine-implementable way to assess if a language subtag is for a sign language.
Therefore I included this text in the latest proposal for section 5.4 at the link that Bernard provided:

" 
A specific sign language can be identified by its existence in the IANA 
registry of language subtags according to BCP 47 [RFC5646] , and finding 
that the language subtag is found at least in two entries in the 
registry, once with the Type field "language" and once with the Type 
field "extlang" combined with the Prefix field value "sgn".
"

So that should be the response on Dales request to easily decide if a language tag is for a sign language.

Worse is next topic in issue 43: to assess if a language tag is for a spoken modality or written modality of a language.
My wording proposal starts with the obvious cases: a non-signed languge tag in audio media is spoken, and a non-signed language tag in text media is written.  But for other cases, like in video or message or application or multiplexed media, other indications must be used to understand the intended modality. The proposed text mentions a few, and leaves to applications to decide which mechanisms to use for such cases. I wish we for the ambiguous cases could use the script subtag -zxxx to indicate spoken modality and a real script subtag even on language subtags where script subtags are suppressed, because that would satisfy issue 43 nicely and make section 5.4 much shorter and clearer. But we have had resistance against that solution.

The proposed text might be a bit long and detailed. I am prepared to agree on a shortened version if there are any proposals. I think though that contents of 5.4 in the direction of my proposal is what satisfies  issue 43 and also the comments lately that section 5.4 is too restrictive.

/Gunnar
 

  


_______________________________________________
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
--------------C4002CE67E9F13948F009B01-- From nobody Sat Nov 18 21:25:19 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 10FD0126BF3 for ; Sat, 18 Nov 2017 21:25:18 -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, 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 w85_2m5SlQM2 for ; Sat, 18 Nov 2017 21:25:15 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 8F244124D37 for ; Sat, 18 Nov 2017 21:25:15 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id g11so3848392vkd.13 for ; Sat, 18 Nov 2017 21:25:15 -0800 (PST) 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=HDS6FKDiXgohsKRFoRkLf7Wfc/MTxUABa4+nZE3KRRM=; b=Q7PUHqS7833Yu2nlSv7PMbrURamRlfbbAXAQPXjbnX6QLFbZ7geQUr/qhkiyiT3ygY 9uUzJsHa0AWohof86idWkyF5GY+lhA3tXh9aWtSyLkIro3rNt6galqJUzT7y6u254hA8 TGMET4VwHxMdItv0AJN0W9XLQugmjLXW2nw7NqbWbDEg4Bs8iVife8EkZIHfQr1eUMUQ klYyT3mSRhIy81dC3Ucrh6WOXO9PUHjU/GP6co0s13WXd6591fzwFTuRGDLGyoMh2EVQ gWNGlNNimiRUhFdjNAw3oL2vZCfd4jZlVCnGCUZRYKA0Ap5mIyTWsXZYVjh/BWcqpUAC sYtw== 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=HDS6FKDiXgohsKRFoRkLf7Wfc/MTxUABa4+nZE3KRRM=; b=ME5Shm29Hm4GultqvMP5evKduNaWjQuBvVdclLBRN8ETJbWzTLvM0b2k7jfdv+7kD2 hthepEvmCnvOp6CqD6DaCFoE7SYgrK2mJ8glxrIZKyJ83TRAg/+e34bzZW4trsCFCtUS dT+5g0RgXlThPXkhDAceP+1yCaWwOJRv3KvWL1lRprfLPhbJkJdi9jP9+TakvFghGn45 LaUyL6bxFP0FI0ZrMfUgYJ8m7YUR7H0JhofkiYDcImeHGkJsoVUqf9ZbU7lYUdUeVyVX 3nIxsEr4tcTJHUjzPCJVh8tA7Jzt5o2c9QFm7aDSTn8KYemdH3faWJF3ZxNKBJ/nFre5 ASeg== X-Gm-Message-State: AJaThX762xo9d48UvFzQ+4f6NjmiWcoV6TFC0Pb+LZnWEu3hxb+hA0n6 RTx8epDTTfJmV1XAwmfal6Y42Slte4QA3L86UGXXabDb X-Google-Smtp-Source: AGs4zMZxZyMupASFl66XsKlo43IgrMciZAuhFEhB98YKT7stNQViskFidJ4FDqGdvRf/rpP0L/9LQJg9TGMazRT3n3A= X-Received: by 10.31.5.66 with SMTP id 63mr7764814vkf.15.1511069114238; Sat, 18 Nov 2017 21:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Sat, 18 Nov 2017 21:24:53 -0800 (PST) In-Reply-To: <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se> References: <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se> From: Bernard Aboba Date: Sat, 18 Nov 2017 21:24:53 -0800 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: slim@ietf.org Content-Type: multipart/alternative; boundary="001a1143dd5ac90e12055e4f31fa" Archived-At: Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language 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: Sun, 19 Nov 2017 05:25:18 -0000 --001a1143dd5ac90e12055e4f31fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunnar said: "I earlier thought that an application needed to look into the language subtag Description to find the word "sign" there in the text string. That is not a good solution." [BA] Agreed. Also, as indicated in RFC 5646 Section 4.1.2 and the IANA registry ( https://www.iana.org/assignments/language-subtag-registry/language-subtag-r= egistry), sign languages may not have always have a subtag of 'sgn': Sign languages share a mode of communication rather than a linguistic heritage. There are many sign languages that have developed independently, and the subtag 'sgn' indicates only the presence of a sign language. A number of sign languages also had grandfathered tags registered for them during the RFC 3066 era. For example, the grandfathered tag "sgn-US" was registered to represent 'American Sign Language' specifically, without reference to the United States. This is still valid, but deprecated: a document in American Sign Language can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the language called 'American Sign Language'). Gunnar also said: "A specific sign language can be identified by its existence in the IANA registry of language subtags according to BCP 47 [RFC5646] , and finding that the language subtag is found at least in two entries in the registry, once with the Type field "language" and once with the Type field "extlang" combined with the Prefix field value "sgn". So that should be the response on Dales request to easily decide if a language tag is for a sign language. " [BA] Looking at the IANA registry, having a Type field "extlang" combined with the Prefix field value 'sgn' seems to be used as an indicator of a sign language. Do you think we can rely on this? Currently this is only a SHOULD in RFC 5646 Section 3.4: 3. Sign languages SHOULD have an 'extlang' record with an'Prefix' of 'sgn'. "My wording proposal starts with the obvious cases: a non-signed language tag in audio media is spoken, and a non-signed language tag in text media is written." [BA] Assuming your suggested approach allows us to reliably determine non-sign languages, this seems solid. Gunnar further said: "But for other cases, like in video or message or application or multiplexed media, other indications must be used to understand the intended modality... I wish for the ambiguous cases we could use the script subtag -zxxx to indicate spoken modality and a real script subtag..." [BA] This is where I become uneasy, because without an explicit mechanism such as script subtags, there is the potential for ambiguity. Trying to address reduce that ambiguity via heuristics could turn out to be a bad idea, compared with proceeding more cautiously by leaving behavior undefined for now and revisiting the situation later when we understand the problem better. For example: "Use for sending of a visual view of a speaking person may be indicated by the value "speaker" in an SDP Content attribute according to RFC 4796 [RFC4796] in a "video" media stream or another media carrying video (e.g. "message" or "application")." [BA] There are quite a few potential corner cases here. For example, if "en-US" language is included in an offer within a video m-line, should the answerer assume this implies a willingness to lip read US English if the value "speaker" is in the Content attribute? What can be assumed if a value other than "speaker" is in the Content attribute? Might that represent something entirely different, such as the desire to receive captioning in US English? If so, how could the Offerer indicate both the capability of lipreading and the ability to handle captions? And what happens if the Answerer doesn't mimic the Content attribute in the Offer? Seems like there are some potential "gotchas" here. "Use of written modality in another media stream than "text", may be discriminated by use of a script subtag in the language tag, where that is appropriate." [BA] What if the language in question has script subtags suppressed? What if the Offerer includes a script subtag in the video m-line but also "speaker" in the Content attribute? Again, there could be quite a few corner cases lurking here. On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Thanks Bernard for pushing for closing the last open issue. > Den 2017-11-18 kl. 19:46, skrev Bernard Aboba: > > At this point, only a single Issue (43) remains open on > draft-ietf-slim-negotiating-human-language:: > https://trac.ietf.org/trac/slim/ticket/43 > > This relates to the modality of a language indication. > > Currently, Gunnar has suggested a modification to the text of Section 5.4 > in order to address the issue: > https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g > > > Can WG participants review this suggested change, so that we can determin= e > how to move forward? > > Currently, Section 5.4 states that: > > The problem of knowing which language tags are signed and which are > not is out of scope of this document. > > I earlier thought that an application needed to look into the language > subtag Description to find the word "sign" there in the text string. That > is not a good solution. But when studying the topic again in RFC 5646 I > found that there is a consistent machine-implementable way to assess if a > language subtag is for a sign language. > Therefore I included this text in the latest proposal for section 5.4 at > the link that Bernard provided: > > " > > A specific sign language can be identified by its existence in the IANA > registry of language subtags according to BCP 47 [RFC5646] , and finding > that the language subtag is found at least in two entries in the > registry, once with the Type field "language" and once with the Type > field "extlang" combined with the Prefix field value "sgn". > > " > > So that should be the response on Dales request to easily decide if a > language tag is for a sign language. > > Worse is next topic in issue 43: to assess if a language tag is for a > spoken modality or written modality of a language. > My wording proposal starts with the obvious cases: a non-signed languge > tag in audio media is spoken, and a non-signed language tag in text media > is written. But for other cases, like in video or message or application > or multiplexed media, other indications must be used to understand the > intended modality. The proposed text mentions a few, and leaves to > applications to decide which mechanisms to use for such cases. I wish we > for the ambiguous cases could use the script subtag -zxxx to indicate > spoken modality and a real script subtag even on language subtags where > script subtags are suppressed, because that would satisfy issue 43 nicely > and make section 5.4 much shorter and clearer. But we have had resistance > against that solution. > > The proposed text might be a bit long and detailed. I am prepared to agre= e > on a shortened version if there are any proposals. I think though that > contents of 5.4 in the direction of my proposal is what satisfies issue = 43 > and also the comments lately that section 5.4 is too restrictive. > > /Gunnar > > > > > > > _______________________________________________ > SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim > > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitorgunnar.hellstrom@omnitor.se > +46 708 204 288 > > --001a1143dd5ac90e12055e4f31fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0

"I earlier thought that an application needed to look int= o the language subtag Description to find the word "sign" there i= n the text string. That is not a good solution."

=
[BA] Agreed. Also, as indicated in RFC 5646 Section 4.1.2 and th= e IANA registry (https://www.iana.org/assignments/langu= age-subtag-registry/language-subtag-registry), sign languages may not h= ave always have a subtag of 'sgn':=C2=A0

<= pre class=3D"gmail-newpage" style=3D"color:rgb(0,0,0);font-size:13.3333px;m= argin-top:0px;margin-bottom:0px"> Sign languages share a mode of communic= ation rather than a linguistic heritage. There are many sign languages that have developed independently, and the subtag 'sgn' indicates only the presence = of a sign language. A number of sign languages also had grandfathered tags registered for them during the RFC 3066 era. For example, the grandfathered tag "sgn-US" was registered to represent 'Am= erican Sign Language' specifically, without reference to the United States. Thi= s is still valid, but deprecated: a document in American Sign Language can be labeled either "ase" or "sgn-ase" (the 'a= se' subtag is for the language called 'American Sign Language').

<= /div>
Gunnar also said:=C2=A0

"A specific sign languag=
e can be identified by its existence in the IANA=20
registry of language subtags according to BCP 47 [RFC5646] , and finding=20
that the language subtag is found at least in two entries in the=20
registry, once with the Type field "language" and once with the T=
ype=20
field "extlang" combined with the Prefix field value "sgn&qu=
ot;.

So that shou= ld be the response on Dales request to easily decide if a language tag is f= or a sign language.=C2=A0&qu= ot;

[BA]=C2=A0 Looking at the IANA registry, havin= g a Type field "extlang" combined with the Prefix field value = 9;sgn' seems to be used as an indicator of a sign language.=C2=A0 Do yo= u think we can rely on this? Currently this is only a SHOULD=C2=A0 in RFC 5= 646 Section 3.4:=C2=A0

            3.  Sign languages SHOULD have an 'extlang'=
 record with an'Prefix' of 'sgn'.


"My wordi=
ng proposal starts with the obvious cases: a non-signed language tag in aud=
io media is spoken, and a non-signed language tag in text media is written.=
"

[BA] Assuming your suggested approach allows us to =
reliably determine non-sign languages, this seems solid. 

Gunnar =
further said: 

"But for other cases, like in video or message=
 or application or multiplexed media, other indications must be used to 
understand the intended modality... I =
wish for the ambiguous cases we could use the script subtag -zxxx to indica=
te
spoken modality and a real script=
 subtag..."

[BA] This is where I become uneasy, because withou=
t an explicit mechanism such as script subtags, there is the potential for =
ambiguity.
Trying to address reduce =
that ambiguity via heuristics could turn out to be a bad idea, compared wit=
h proceeding more cautiously 
by lea=
ving behavior undefined for now and revisiting the situation later when we =
understand the problem better. For example: 

"Use=
 for sending of a visual view of a speaking person may be indicated by the =
value "speaker" in an SDP=20
Content attribute according to RFC 4796 [RFC4796] in a "video" me=
dia stream or another media carrying video (e.g. "message" or &qu=
ot;application")."
[BA] There are quite a few potentia=
l corner cases here. For example, if "en-US" language is included=
 in an offer within a video m-line, should the answerer assume this implies=
 a willingness to lip read US English if the value "speaker" is i=
n the Content attribute?  What can be assumed if a value other than "s=
peaker" is in the Content attribute? Might that represent something en=
tirely different, such as the desire to receive captioning in US English? I=
f so, how could the Offerer indicate both the capability of lipreading and =
the ability to handle captions? And what happens if the Answerer doesn'=
t mimic the Content attribute in the Offer? Seems like there are some poten=
tial "gotchas" here.
"Use of written modality in another media stream than 
&qu=
ot;text", may be discriminated by use of a script subtag in the langua=
ge=20
tag, where that is appropriate."
[BA] What if the language =
in question has script subtags suppressed? What if the Offerer includes a s=
cript subtag in the video m-line but also "speaker" in the Conten=
t attribute? Again, there could be quite a few corner cases lurking here. <=
/pre>



<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">





On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellstr=C3= =B6m <gunnar.hellstrom@omnitor.se> wrote:
=20 =20 =20
Thanks Bernard for pushing for closing the last open issue.
Den 2017-11-18 kl. 19:46, skrev Bernard Aboba:
At this point, only a single Issue (43) remains open on draft-ietf-slim-negotiating-human-language::=C2=A0

This relates to the modality of a language indication.=C2=A0

Currently, Gunnar has suggested a modification to the text of Section 5.4 in order to address the issue:=C2=A0


Can WG participants review this suggested change, so that we can determine how to move forward?=C2=A0

Currently, Section 5.4 states that:=C2=A0

   The problem of knowing which language tags are signed and which=
 are
   not is out of scope of this document.
I earlier thought that an application needed to look into the language subtag Description to find the word "sign" there in = the text string. That is not a good solution. But when studying the topic again in RFC 5646 I found that there is a consistent machine-implementable way to assess if a language subtag is for a sign language.
Therefore I included this text in the latest proposal for section 5.4 at the link that Bernard provided:

" 
A specific sign language can be identified by its e=
xistence in the IANA=20
registry of language subtags according to BCP 47 [RFC5646] , and finding=20
that the language subtag is found at least in two entries in the=20
registry, once with the Type field "language" and once with the T=
ype=20
field "extlang" combined with the Prefix field value "sgn&qu=
ot;.
"

So that should be the response on Dales request to easily decide if a language tag is for a sign language.

Worse is next topic in issue 43: to assess if a language tag is for a spoken modality or written modality of a language.
My wording proposal starts with the obvious cases: a non-signed languge tag in audio media is spoken, and a non-signed language tag in text media is written.=C2=A0 But for other cases, like in video or message or application or multiplexed media, other indications must be used to understand the intended modality. The proposed text mentions a few, and leaves to applications to decide which mechanisms to use for such cases. I wish we for the ambiguous cases could use the script subtag -zxxx to indicate spoken modality and a real script subtag even on language subtags where script subtags are suppressed, because that would satisfy issue 43 nicely and make section 5.4 much shorter and clearer. But we have had resistance against that solution.

The proposed text might be a bit long and detailed. I am prepared to agree on a shortened version if there are any proposals. I think though that contents of 5.4 in the direction of my proposal is what satisfies=C2=A0 issue 43 and also the comments lately that section 5.4 = is too restrictive.

/Gunnar
=C2=A0

=C2=A0 


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


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

--001a1143dd5ac90e12055e4f31fa-- From nobody Sun Nov 19 02:41:04 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 1D79C1200FC for ; Sun, 19 Nov 2017 02:41:02 -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 Ct-ozw3BSNQg for ; Sun, 19 Nov 2017 02:40:59 -0800 (PST) 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 BF0671200C1 for ; Sun, 19 Nov 2017 02:40:58 -0800 (PST) X-Halon-ID: 18762ae7-cd16-11e7-96ac-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 18762ae7-cd16-11e7-96ac-005056917f90; Sun, 19 Nov 2017 11:40:44 +0100 (CET) To: Bernard Aboba Cc: slim@ietf.org References: <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <7cf08f46-af12-a18b-b9e0-a0b14be7c816@omnitor.se> Date: Sun, 19 Nov 2017 11:40:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7EBCE60112A79A8F382445A8" Content-Language: en-US Archived-At: Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language 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: Sun, 19 Nov 2017 10:41:02 -0000 This is a multi-part message in MIME format. --------------7EBCE60112A79A8F382445A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Den 2017-11-19 kl. 06:24, skrev Bernard Aboba: > Gunnar said: > > "I earlier thought that an application needed to look into the > language subtag Description to find the word "sign" there in the text > string. That is not a good solution." > > [BA] Agreed. Also, as indicated in RFC 5646 Section 4.1.2 and the IANA > registry > (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), > sign languages may not have always have a subtag of 'sgn': > > Sign languages share a mode of communication rather than a linguistic > heritage. There are many sign languages that have developed > independently, and the subtag 'sgn' indicates only the presence of a > sign language. A number of sign languages also had grandfathered > tags registered for them during theRFC 3066 era. For example, the > grandfathered tag "sgn-US" was registered to represent 'American Sign > Language' specifically, without reference to the United States. This > is still valid, but deprecated: a document in American Sign Language > can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the > language called 'American Sign Language'). > Right. It cannot be seen by the language tag itself if it is a sign language. You need to interrogate the IANA registry. > Gunnar also said: > > "A specific sign language can be identified by its existence in the IANA > registry of language subtags according to BCP 47 [RFC5646] , and finding > that the language subtag is found at least in two entries in the > registry, once with the Type field "language" and once with the Type > field "extlang" combined with the Prefix field value "sgn". > > So that should be the response on Dales request to easily decide if a > language tag is for a sign language." > > [BA]  Looking at the IANA registry, having a Type field "extlang" > combined with the Prefix field value 'sgn' seems to be used as an > indicator of a sign language.  Do you think we can rely on this? > Currently this is only a SHOULD  in RFC 5646 Section 3.4: > > 3. Sign languages SHOULD have an 'extlang' record with an'Prefix' of 'sgn'. Yes, it is a SHOULD. But all registered sign languages so far follow this rule, so I think it is solid. Do you think we need to weaken the start of our recommended procedure: "A specific sign language can be identified...." The "can" could be weakened, but I do not think we need to do so. > "My wording proposal starts with the obvious cases: a non-signed > language tag in audio media is spoken, and a non-signed language tag > in text media is written." Among the three obvious cases are also that sign languages in video media are signed. > [BA] Assuming your suggested approach allows us to reliably determine non-sign languages, this seems solid. > Gunnar further said: > "But for other cases, like in video or message or application or multiplexed media, other indications must be used to > understand the intended modality... I wish for the ambiguous cases we could use the script subtag -zxxx to indicate > spoken modality and a real script subtag..." > [BA] This is where I become uneasy, because without an explicit mechanism such as script subtags, there is the potential for ambiguity. > Trying to address reduce that ambiguity via heuristics could turn out to be a bad idea, compared with proceeding more cautiously > by leaving behavior undefined for now and revisiting the situation later when we understand the problem better. For example: > "Use for sending of a visual view of a speaking person may be indicated by the value "speaker" in an SDP > Content attribute according to RFC 4796 [RFC4796] in a "video" media stream or another media carrying video (e.g. "message" or "application")." > [BA] There are quite a few potential corner cases here. For example, if "en-US" language is included in an offer within a video m-line, should the answerer assume this implies a willingness to lip read US English if the value "speaker" is in the Content attribute? What can be assumed if a value other than "speaker" is in the Content attribute? Might that represent something entirely different, such as the desire to receive captioning in US English? If so, how could the Offerer indicate both the capability of lipreading and the ability to handle captions? And what happens if the Answerer doesn't mimic the Content attribute in the Offer? Seems like there are some potential "gotchas" here. Yes, I agree that the hint to use the "Content" attribute was not solid. One problem with it is that it is said to indicate only what is to be sent in the media, so we have no way to use it for desired received modality. Thereby it cannot be used as a confirmation from the answering party. So it is a weak hint and may confuse more than it helps. The idea was however to be informative guide to a number of possible ways for applications to indicate modality when it is not one of the three obvious cases. We can delete the hint about the "Content" attribute. > "Use of written modality in another media stream than > "text", may be discriminated by use of a script subtag in the language > tag, where that is appropriate." > [BA] What if the language in question has script subtags suppressed? What if the Offerer includes a script subtag in the video m-line but also "speaker" in the Content attribute? Again, there could be quite a few corner cases lurking here. The application must not create illogical combinations. But let us drop the "Content" attribute hint. I find the use of the script subtag much more solid for the otherwise ambiguous cases. RFC 5646 clearly says that it is allowed to use even suppressed script subtags when its use has an important discriminating meaning. (Section 4.1 of RFC 5646 says: "The script subtag SHOULD NOT be used to form language tags unless the script adds some distinguishing information to the tag." That is true for our case. The problem is that we have had persistent resistance from the language experts for both using suppressed script substags for written modality and using the -Zxxx script subtag for spoken modality.  Can we explain our case better and get a go ahead from the language experts? That would result in a really simple set of rules. Gunnar > > > On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellström > > wrote: > > Thanks Bernard for pushing for closing the last open issue. > Den 2017-11-18 kl. 19:46, skrev Bernard Aboba: >> At this point, only a single Issue (43) remains open on >> draft-ietf-slim-negotiating-human-language:: >> https://trac.ietf.org/trac/slim/ticket/43 >> >> >> This relates to the modality of a language indication. >> >> Currently, Gunnar has suggested a modification to the text of >> Section 5.4 in order to address the issue: >> https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g >> >> >> >> Can WG participants review this suggested change, so that we can >> determine how to move forward? >> >> Currently, Section 5.4 states that: >> >> The problem of knowing which language tags are signed and which are >> not is out of scope of this document. > I earlier thought that an application needed to look into the > language subtag Description to find the word "sign" there in the > text string. That is not a good solution. But when studying the > topic again in RFC 5646 I found that there is a consistent > machine-implementable way to assess if a language subtag is for a > sign language. > Therefore I included this text in the latest proposal for section > 5.4 at the link that Bernard provided: > > " > > A specific sign language can be identified by its existence in the IANA > registry of language subtags according to BCP 47 [RFC5646] , and finding > that the language subtag is found at least in two entries in the > registry, once with the Type field "language" and once with the Type > field "extlang" combined with the Prefix field value "sgn". > > " > > So that should be the response on Dales request to easily decide > if a language tag is for a sign language. > > Worse is next topic in issue 43: to assess if a language tag is > for a spoken modality or written modality of a language. > My wording proposal starts with the obvious cases: a non-signed > languge tag in audio media is spoken, and a non-signed language > tag in text media is written.  But for other cases, like in video > or message or application or multiplexed media, other indications > must be used to understand the intended modality. The proposed > text mentions a few, and leaves to applications to decide which > mechanisms to use for such cases. I wish we for the ambiguous > cases could use the script subtag -zxxx to indicate spoken > modality and a real script subtag even on language subtags where > script subtags are suppressed, because that would satisfy issue 43 > nicely and make section 5.4 much shorter and clearer. But we have > had resistance against that solution. > > The proposed text might be a bit long and detailed. I am prepared > to agree on a shortened version if there are any proposals. I > think though that contents of 5.4 in the direction of my proposal > is what satisfies  issue 43 and also the comments lately that > section 5.4 is too restrictive. > > /Gunnar > > >> >> >> _______________________________________________ >> 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 --------------7EBCE60112A79A8F382445A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICBEZW4gMjAxNy0xMS0x OSBrbC4gMDY6MjQsIHNrcmV2IEJlcm5hcmQgQWJvYmE6PGJyPg0KICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiDQpjaXRlPSJtaWQ6Q0FPVysyZHVxOXFrWEJ5OFMrYV9HU3BtUHd5cE1H TGZZTDNWOVpaZmtyRHJhU0ErUzF3QG1haWwuZ21haWwuY29tIj4NCiAgICAgIDxkaXYgZGly PSJsdHIiPkd1bm5hciBzYWlkOsKgDQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rp dj4NCiAgICAgICAgPGRpdj4iPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPkkgZWFy bGllciB0aG91Z2h0IHRoYXQgYW4NCiAgICAgICAgICAgIGFwcGxpY2F0aW9uIG5lZWRlZCB0 byBsb29rIGludG8gdGhlIGxhbmd1YWdlIHN1YnRhZw0KICAgICAgICAgICAgRGVzY3JpcHRp b24gdG8gZmluZCB0aGUgd29yZCAic2lnbiIgdGhlcmUgaW4gdGhlIHRleHQNCiAgICAgICAg ICAgIHN0cmluZy4gVGhhdCBpcyBub3QgYSBnb29kIHNvbHV0aW9uLjwvc3Bhbj4iPC9kaXY+ DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj5bQkFd IEFncmVlZC4gQWxzbywgYXMgaW5kaWNhdGVkIGluIFJGQyA1NjQ2IFNlY3Rpb24gNC4xLjIN CiAgICAgICAgICBhbmQgdGhlIElBTkEgcmVnaXN0cnkgKDxhDQpocmVmPSJodHRwczovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9sYW5ndWFnZS1zdWJ0YWctcmVnaXN0cnkvbGFuZ3Vh Z2Utc3VidGFnLXJlZ2lzdHJ5Ig0KICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ij5odHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9sYW5ndWFnZS1zdWJ0YWctcmVn aXN0cnkvbGFuZ3VhZ2Utc3VidGFnLXJlZ2lzdHJ5PC9hPiksDQogICAgICAgICAgc2lnbiBs YW5ndWFnZXMgbWF5IG5vdCBoYXZlIGFsd2F5cyBoYXZlIGEgc3VidGFnIG9mICdzZ24nOsKg PC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRp dj4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iY29sb3I6 cmdiKDAsMCwwKTtmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1i b3R0b206MHB4Ij4gICBTaWduIGxhbmd1YWdlcyBzaGFyZSBhIG1vZGUgb2YgY29tbXVuaWNh dGlvbiByYXRoZXIgdGhhbiBhIGxpbmd1aXN0aWMNCiAgIGhlcml0YWdlLiAgVGhlcmUgYXJl IG1hbnkgc2lnbiBsYW5ndWFnZXMgdGhhdCBoYXZlIGRldmVsb3BlZA0KICAgaW5kZXBlbmRl bnRseSwgYW5kIHRoZSBzdWJ0YWcgJ3NnbicgaW5kaWNhdGVzIG9ubHkgdGhlIHByZXNlbmNl IG9mIGENCiAgIHNpZ24gbGFuZ3VhZ2UuICBBIG51bWJlciBvZiBzaWduIGxhbmd1YWdlcyBh bHNvIGhhZCBncmFuZGZhdGhlcmVkDQogICB0YWdzIHJlZ2lzdGVyZWQgZm9yIHRoZW0gZHVy aW5nIHRoZSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzA2NiIg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5SRkMgMzA2NjwvYT4gZXJhLiAgRm9yIGV4YW1wbGUs IHRoZQ0KICAgZ3JhbmRmYXRoZXJlZCB0YWcgInNnbi1VUyIgd2FzIHJlZ2lzdGVyZWQgdG8g cmVwcmVzZW50ICdBbWVyaWNhbiBTaWduDQogICBMYW5ndWFnZScgc3BlY2lmaWNhbGx5LCB3 aXRob3V0IHJlZmVyZW5jZSB0byB0aGUgVW5pdGVkIFN0YXRlcy4gIFRoaXMNCiAgIGlzIHN0 aWxsIHZhbGlkLCBidXQgZGVwcmVjYXRlZDogYSBkb2N1bWVudCBpbiBBbWVyaWNhbiBTaWdu IExhbmd1YWdlDQogICBjYW4gYmUgbGFiZWxlZCBlaXRoZXIgImFzZSIgb3IgInNnbi1hc2Ui ICh0aGUgJ2FzZScgc3VidGFnIGlzIGZvciB0aGUNCiAgIGxhbmd1YWdlIGNhbGxlZCAnQW1l cmljYW4gU2lnbiBMYW5ndWFnZScpLjwvcHJlPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1 b3RlPg0KICAgICZsdDtHSCZndDtSaWdodC4gSXQgY2Fubm90IGJlIHNlZW4gYnkgdGhlIGxh bmd1YWdlIHRhZyBpdHNlbGYgaWYgaXQNCiAgICBpcyBhIHNpZ24gbGFuZ3VhZ2UuIFlvdSBu ZWVkIHRvIGludGVycm9nYXRlIHRoZSBJQU5BIHJlZ2lzdHJ5LiA8YnI+DQogICAgPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1pZDpDQU9XKzJkdXE5cWtYQnk4UythX0dTcG1Q d3lwTUdMZllMM1Y5Wlpma3JEcmFTQStTMXdAbWFpbC5nbWFpbC5jb20iPg0KICAgICAgPGRp diBkaXI9Imx0ciI+DQogICAgICAgIDxkaXY+R3VubmFyIGFsc28gc2FpZDrCoDwvZGl2Pg0K ICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+DQogICAg ICAgICAgPHByZSBjbGFzcz0iZ21haWwtbV8xOTEwNzIwNDA4MDQwMDc3Mzcxd29yZHdyYXAi IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDtib3gtc2l6aW5nOmJvcmRlci1ib3g7b3Zl cmZsb3c6YXV0bztmb250LWZhbWlseTpNZW5sbyxNb25hY28sQ29uc29sYXMsJnF1b3Q7Q291 cmllciBOZXcmcXVvdDssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4O3BhZGRpbmc6MHB4O21h cmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MTBweDtsaW5lLWhlaWdodDoxLjQyODU3O3dv cmQtYnJlYWs6bm9ybWFsO3dvcmQtd3JhcDpub3JtYWw7Y29sb3I6cmdiKDUxLDUxLDUxKTti b3JkZXI6MHB4IG5vbmUgYmxhY2s7Ym9yZGVyLXJhZGl1czo0cHgiPiJBIHNwZWNpZmljIHNp Z24gbGFuZ3VhZ2UgY2FuIGJlIGlkZW50aWZpZWQgYnkgaXRzIGV4aXN0ZW5jZSBpbiB0aGUg SUFOQSANCnJlZ2lzdHJ5IG9mIGxhbmd1YWdlIHN1YnRhZ3MgYWNjb3JkaW5nIHRvIEJDUCA0 NyBbUkZDNTY0Nl0gLCBhbmQgZmluZGluZyANCnRoYXQgdGhlIGxhbmd1YWdlIHN1YnRhZyBp cyBmb3VuZCBhdCBsZWFzdCBpbiB0d28gZW50cmllcyBpbiB0aGUgDQpyZWdpc3RyeSwgb25j ZSB3aXRoIHRoZSBUeXBlIGZpZWxkICJsYW5ndWFnZSIgYW5kIG9uY2Ugd2l0aCB0aGUgVHlw ZSANCmZpZWxkICJleHRsYW5nIiBjb21iaW5lZCB3aXRoIHRoZSBQcmVmaXggZmllbGQgdmFs dWUgInNnbiIuPC9wcmU+DQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+U28gdGhh dCBzaG91bGQgYmUgdGhlDQogICAgICAgICAgICAgIHJlc3BvbnNlIG9uIERhbGVzIHJlcXVl c3QgdG8gZWFzaWx5IGRlY2lkZSBpZiBhIGxhbmd1YWdlDQogICAgICAgICAgICAgIHRhZyBp cyBmb3IgYSBzaWduIGxhbmd1YWdlLjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICBzdHls ZT0iZm9udC1zaXplOjEyLjhweCI+wqA8L3NwYW4+IjwvZGl2Pg0KICAgICAgICAgIDxkaXY+ PGJyPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDxkaXY+W0JBXcKgIExvb2tpbmcg YXQgdGhlIElBTkEgcmVnaXN0cnksIGhhdmluZyBhIFR5cGUgZmllbGQNCiAgICAgICAgICAg ICJleHRsYW5nIiBjb21iaW5lZCB3aXRoIHRoZSBQcmVmaXggZmllbGQgdmFsdWUgJ3Nnbicg c2VlbXMNCiAgICAgICAgICAgIHRvIGJlIHVzZWQgYXMgYW4gaW5kaWNhdG9yIG9mIGEgc2ln biBsYW5ndWFnZS7CoCBEbyB5b3UgdGhpbmsNCiAgICAgICAgICAgIHdlIGNhbiByZWx5IG9u IHRoaXM/IEN1cnJlbnRseSB0aGlzIGlzIG9ubHkgYSBTSE9VTETCoCBpbiBSRkMNCiAgICAg ICAgICAgIDU2NDYgU2VjdGlvbiAzLjQ6wqA8L2Rpdj4NCiAgICAgICAgICA8ZGl2Pg0KICAg ICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJm b250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2Nv bG9yOnJnYigwLDAsMCkiPiAgICAgICAgICAgIDMuICBTaWduIGxhbmd1YWdlcyBTSE9VTEQg aGF2ZSBhbiAnZXh0bGFuZycgcmVjb3JkIHdpdGggYW4nUHJlZml4JyBvZiAnc2duJy48L3By ZT4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rp dj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICAmbHQ7R0gmZ3Q7WWVz LCBpdCBpcyBhIFNIT1VMRC4gQnV0IGFsbCByZWdpc3RlcmVkIHNpZ24gbGFuZ3VhZ2VzIHNv DQogICAgZmFyIGZvbGxvdyB0aGlzIHJ1bGUsIHNvIEkgdGhpbmsgaXQgaXMgc29saWQuIERv IHlvdSB0aGluayB3ZSBuZWVkDQogICAgdG8gd2Vha2VuIHRoZSBzdGFydCBvZiBvdXIgcmVj b21tZW5kZWQgcHJvY2VkdXJlOiA8YnI+DQogICAgPHByZSBjbGFzcz0iZ21haWwtbV8xOTEw NzIwNDA4MDQwMDc3Mzcxd29yZHdyYXAiIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDti b3gtc2l6aW5nOmJvcmRlci1ib3g7b3ZlcmZsb3c6YXV0bztmb250LWZhbWlseTpNZW5sbyxN b25hY28sQ29uc29sYXMsJnF1b3Q7Q291cmllciBOZXcmcXVvdDssbW9ub3NwYWNlO2ZvbnQt c2l6ZToxM3B4O3BhZGRpbmc6MHB4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MTBw eDtsaW5lLWhlaWdodDoxLjQyODU3O3dvcmQtYnJlYWs6bm9ybWFsO3dvcmQtd3JhcDpub3Jt YWw7Y29sb3I6cmdiKDUxLDUxLDUxKTtib3JkZXI6MHB4IG5vbmUgYmxhY2s7Ym9yZGVyLXJh ZGl1czo0cHgiPiJBIHNwZWNpZmljIHNpZ24gbGFuZ3VhZ2UgY2FuIGJlIGlkZW50aWZpZWQu Li4uIiAgIFRoZSAiY2FuIiBjb3VsZCBiZSB3ZWFrZW5lZCwgYnV0IEkgZG8gbm90IHRoaW5r IHdlIG5lZWQgdG8gZG8gc28uPC9wcmU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIN CmNpdGU9Im1pZDpDQU9XKzJkdXE5cWtYQnk4UythX0dTcG1Qd3lwTUdMZllMM1Y5Wlpma3JE cmFTQStTMXdAbWFpbC5nbWFpbC5jb20iPg0KICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAg ICAgIDxkaXY+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgIDxkaXY+DQogICAgICAg ICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMu MzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAs MCkiPg0KPC9wcmU+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2Ui IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0 b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4 O2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6cmdiKDM0LDM0LDM0KSI+DQo8 L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2Ui IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0 b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDtjb2xvcjpyZ2IoMzQsMzQsMzQpIj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHg7Zm9udC1mYW1pbHk6YXJpYWwsc2Fu cy1zZXJpZjtjb2xvcjpyZ2IoMzQsMzQsMzQpIj4iTXkgd29yZGluZyBwcm9wb3NhbCBzdGFy dHMgd2l0aCB0aGUgb2J2aW91cyBjYXNlczogYSBub24tc2lnbmVkIGxhbmd1YWdlIHRhZyBp biBhdWRpbyBtZWRpYSBpcyBzcG9rZW4sIGFuZCBhIG5vbi1zaWduZWQgbGFuZ3VhZ2UgdGFn IGluIHRleHQgbWVkaWEgaXMgd3JpdHRlbi48L3NwYW4+IjwvcHJlPg0KICAgICAgICAgICAg ICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNw eDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj4N CjwvcHJlPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPC9kaXY+DQogICAgICAg IDwvZGl2Pg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgICZsdDtHSCZn dDtBbW9uZyB0aGUgdGhyZWUgb2J2aW91cyBjYXNlcyBhcmUgYWxzbyB0aGF0IHNpZ24gbGFu Z3VhZ2VzDQogICAgaW4gdmlkZW8gbWVkaWEgYXJlIHNpZ25lZC48YnI+DQogICAgPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1pZDpDQU9XKzJkdXE5cWtYQnk4UythX0dTcG1Q d3lwTUdMZllMM1Y5Wlpma3JEcmFTQStTMXdAbWFpbC5nbWFpbC5jb20iPg0KICAgICAgPGRp diBkaXI9Imx0ciI+DQogICAgICAgIDxkaXY+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0 eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206 MHB4O2NvbG9yOnJnYigwLDAsMCkiPltCQV0gQXNzdW1pbmcgeW91ciBzdWdnZXN0ZWQgYXBw cm9hY2ggYWxsb3dzIHVzIHRvIHJlbGlhYmx5IGRldGVybWluZSBub24tc2lnbiBsYW5ndWFn ZXMsIHRoaXMgc2VlbXMgc29saWQuIDwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNz PSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9w OjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAg ICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXpl OjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2Io MCwwLDApIj5HdW5uYXIgZnVydGhlciBzYWlkOiA8L3ByZT4NCiAgICAgICAgICAgICAgPHBy ZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFy Z2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+DQo8L3By ZT4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZv bnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29s b3I6cmdiKDAsMCwwKSI+IkJ1dCBmb3Igb3RoZXIgY2FzZXMsIGxpa2UgaW4gdmlkZW8gb3Ig bWVzc2FnZSBvciBhcHBsaWNhdGlvbiBvciBtdWx0aXBsZXhlZCBtZWRpYSwgb3RoZXIgaW5k aWNhdGlvbnMgbXVzdCBiZSB1c2VkIHRvIDwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNs YXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4t dG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj51bmRlcnN0YW5k IHRoZSBpbnRlbmRlZCBtb2RhbGl0eS4uLiBJIHdpc2ggZm9yIHRoZSBhbWJpZ3VvdXMgY2Fz ZXMgd2UgY291bGQgdXNlIHRoZSBzY3JpcHQgc3VidGFnIC16eHh4IHRvIGluZGljYXRlPC9w cmU+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJm b250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2Nv bG9yOnJnYigwLDAsMCkiPnNwb2tlbiBtb2RhbGl0eSBhbmQgYSByZWFsIHNjcmlwdCBzdWJ0 YWcuLi4iPC9wcmU+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2Ui IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0 b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9wcmU+DQogICAgICAgICAgICAgIDxwcmUg Y2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdp bi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPltCQV0gVGhp cyBpcyB3aGVyZSBJIGJlY29tZSB1bmVhc3ksIGJlY2F1c2Ugd2l0aG91dCBhbiBleHBsaWNp dCBtZWNoYW5pc20gc3VjaCBhcyBzY3JpcHQgc3VidGFncywgdGhlcmUgaXMgdGhlIHBvdGVu dGlhbCBmb3IgYW1iaWd1aXR5LjwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJn bWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBw eDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj5UcnlpbmcgdG8gYWRkcmVz cyByZWR1Y2UgdGhhdCBhbWJpZ3VpdHkgdmlhIGhldXJpc3RpY3MgY291bGQgdHVybiBvdXQg dG8gYmUgYSBiYWQgaWRlYSwgY29tcGFyZWQgd2l0aCBwcm9jZWVkaW5nIG1vcmUgY2F1dGlv dXNseSA8L3ByZT4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIg c3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv bTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+YnkgbGVhdmluZyBiZWhhdmlvciB1bmRlZmluZWQg Zm9yIG5vdyBhbmQgcmV2aXNpdGluZyB0aGUgc2l0dWF0aW9uIGxhdGVyIHdoZW4gd2UgdW5k ZXJzdGFuZCB0aGUgcHJvYmxlbSBiZXR0ZXIuIEZvciBleGFtcGxlOiA8L3ByZT4NCiAgICAg ICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTox My4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAs MCwwKSI+DQo8L3ByZT4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtd29yZHdy YXAiIHN0eWxlPSJib3gtc2l6aW5nOmJvcmRlci1ib3g7b3ZlcmZsb3c6YXV0bztmb250LWZh bWlseTpNZW5sbyxNb25hY28sQ29uc29sYXMsJnF1b3Q7Q291cmllciBOZXcmcXVvdDssbW9u b3NwYWNlO2ZvbnQtc2l6ZToxM3B4O3BhZGRpbmc6MHB4O21hcmdpbi10b3A6MHB4O21hcmdp bi1ib3R0b206MTBweDtsaW5lLWhlaWdodDoxLjQyODU3O3dvcmQtYnJlYWs6bm9ybWFsO3dv cmQtd3JhcDpub3JtYWw7Y29sb3I6cmdiKDUxLDUxLDUxKTtib3JkZXI6MHB4IG5vbmUgYmxh Y2s7Ym9yZGVyLXJhZGl1czo0cHg7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxwcmUgY2xhc3M9 ImdtYWlsLXdvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O292ZXJmbG93 OmF1dG87Zm9udC1mYW1pbHk6TWVubG8sTW9uYWNvLENvbnNvbGFzLCZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LG1vbm9zcGFjZTtwYWRkaW5nOjBweDttYXJnaW4tdG9wOjBweDttYXJnaW4t Ym90dG9tOjEwcHg7bGluZS1oZWlnaHQ6MS40Mjg1Nzt3b3JkLWJyZWFrOm5vcm1hbDt3b3Jk LXdyYXA6bm9ybWFsO2JvcmRlcjowcHggbm9uZSBibGFjaztib3JkZXItcmFkaXVzOjRweDt3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+IlVzZSBmb3Igc2VuZGluZyBvZiBhIHZpc3VhbCB2aWV3 IG9mIGEgc3BlYWtpbmcgcGVyc29uIG1heSBiZSBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlICJz cGVha2VyIiBpbiBhbiBTRFAgDQpDb250ZW50IGF0dHJpYnV0ZSBhY2NvcmRpbmcgdG8gUkZD IDQ3OTYgW1JGQzQ3OTZdIGluIGEgInZpZGVvIiBtZWRpYSBzdHJlYW0gb3IgYW5vdGhlciBt ZWRpYSBjYXJyeWluZyB2aWRlbyAoZS5nLiAibWVzc2FnZSIgb3IgImFwcGxpY2F0aW9uIiku IjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLXdvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzpi b3JkZXItYm94O292ZXJmbG93OmF1dG87Zm9udC1mYW1pbHk6TWVubG8sTW9uYWNvLENvbnNv bGFzLCZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LG1vbm9zcGFjZTtwYWRkaW5nOjBweDttYXJn aW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjEwcHg7bGluZS1oZWlnaHQ6MS40Mjg1Nzt3b3Jk LWJyZWFrOm5vcm1hbDt3b3JkLXdyYXA6bm9ybWFsO2JvcmRlcjowcHggbm9uZSBibGFjazti b3JkZXItcmFkaXVzOjRweDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+W0JBXSBUaGVyZSBhcmUg cXVpdGUgYSBmZXcgcG90ZW50aWFsIGNvcm5lciBjYXNlcyBoZXJlLiBGb3IgZXhhbXBsZSwg aWYgImVuLVVTIiBsYW5ndWFnZSBpcyBpbmNsdWRlZCBpbiBhbiBvZmZlciB3aXRoaW4gYSB2 aWRlbyBtLWxpbmUsIHNob3VsZCB0aGUgYW5zd2VyZXIgYXNzdW1lIHRoaXMgaW1wbGllcyBh IHdpbGxpbmduZXNzIHRvIGxpcCByZWFkIFVTIEVuZ2xpc2ggaWYgdGhlIHZhbHVlICJzcGVh a2VyIiBpcyBpbiB0aGUgQ29udGVudCBhdHRyaWJ1dGU/ICBXaGF0IGNhbiBiZSBhc3N1bWVk IGlmIGEgdmFsdWUgb3RoZXIgdGhhbiAic3BlYWtlciIgaXMgaW4gdGhlIENvbnRlbnQgYXR0 cmlidXRlPyBNaWdodCB0aGF0IHJlcHJlc2VudCBzb21ldGhpbmcgZW50aXJlbHkgZGlmZmVy ZW50LCBzdWNoIGFzIHRoZSBkZXNpcmUgdG8gcmVjZWl2ZSBjYXB0aW9uaW5nIGluIFVTIEVu Z2xpc2g/IElmIHNvLCBob3cgY291bGQgdGhlIE9mZmVyZXIgaW5kaWNhdGUgYm90aCB0aGUg Y2FwYWJpbGl0eSBvZiBsaXByZWFkaW5nIGFuZCB0aGUgYWJpbGl0eSB0byBoYW5kbGUgY2Fw dGlvbnM/IEFuZCB3aGF0IGhhcHBlbnMgaWYgdGhlIEFuc3dlcmVyIGRvZXNuJ3QgbWltaWMg dGhlIENvbnRlbnQgYXR0cmlidXRlIGluIHRoZSBPZmZlcj8gU2VlbXMgbGlrZSB0aGVyZSBh cmUgc29tZSBwb3RlbnRpYWwgImdvdGNoYXMiIGhlcmUuPC9wcmU+PC9wcmU+DQogICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8 L2Rpdj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgJmx0O0dIJmd0O1llcywgSSBhZ3JlZSB0 aGF0IHRoZSBoaW50IHRvIHVzZSB0aGUgIkNvbnRlbnQiIGF0dHJpYnV0ZQ0KICAgIHdhcyBu b3Qgc29saWQuIE9uZSBwcm9ibGVtIHdpdGggaXQgaXMgdGhhdCBpdCBpcyBzYWlkIHRvIGlu ZGljYXRlDQogICAgb25seSB3aGF0IGlzIHRvIGJlIHNlbnQgaW4gdGhlIG1lZGlhLCBzbyB3 ZSBoYXZlIG5vIHdheSB0byB1c2UgaXQNCiAgICBmb3IgZGVzaXJlZCByZWNlaXZlZCBtb2Rh bGl0eS4gVGhlcmVieSBpdCBjYW5ub3QgYmUgdXNlZCBhcyBhDQogICAgY29uZmlybWF0aW9u IGZyb20gdGhlIGFuc3dlcmluZyBwYXJ0eS4gU28gaXQgaXMgYSB3ZWFrIGhpbnQgYW5kIG1h eQ0KICAgIGNvbmZ1c2UgbW9yZSB0aGFuIGl0IGhlbHBzLiA8YnI+DQogICAgVGhlIGlkZWEg d2FzIGhvd2V2ZXIgdG8gYmUgaW5mb3JtYXRpdmUgZ3VpZGUgdG8gYSBudW1iZXIgb2YgcG9z c2libGUNCiAgICB3YXlzIGZvciBhcHBsaWNhdGlvbnMgdG8gaW5kaWNhdGUgbW9kYWxpdHkg d2hlbiBpdCBpcyBub3Qgb25lIG9mIHRoZQ0KICAgIHRocmVlIG9idmlvdXMgY2FzZXMuIFdl IGNhbiBkZWxldGUgdGhlIGhpbnQgYWJvdXQgdGhlICJDb250ZW50Ig0KICAgIGF0dHJpYnV0 ZS48YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1pZDpDQU9XKzJk dXE5cWtYQnk4UythX0dTcG1Qd3lwTUdMZllMM1Y5Wlpma3JEcmFTQStTMXdAbWFpbC5nbWFp bC5jb20iPg0KICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgIDxkaXY+DQogICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9 ImdtYWlsLXdvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O292ZXJmbG93 OmF1dG87Zm9udC1mYW1pbHk6TWVubG8sTW9uYWNvLENvbnNvbGFzLCZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LG1vbm9zcGFjZTtmb250LXNpemU6MTNweDtwYWRkaW5nOjBweDttYXJnaW4t dG9wOjBweDttYXJnaW4tYm90dG9tOjEwcHg7bGluZS1oZWlnaHQ6MS40Mjg1Nzt3b3JkLWJy ZWFrOm5vcm1hbDt3b3JkLXdyYXA6bm9ybWFsO2NvbG9yOnJnYig1MSw1MSw1MSk7Ym9yZGVy OjBweCBub25lIGJsYWNrO2JvcmRlci1yYWRpdXM6NHB4O3doaXRlLXNwYWNlOnByZS13cmFw Ij48cHJlIGNsYXNzPSJnbWFpbC13b3Jkd3JhcCIgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVy LWJveDtvdmVyZmxvdzphdXRvO2ZvbnQtZmFtaWx5Ok1lbmxvLE1vbmFjbyxDb25zb2xhcywm cXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxtb25vc3BhY2U7cGFkZGluZzowcHg7bWFyZ2luLXRv cDowcHg7bWFyZ2luLWJvdHRvbToxMHB4O2xpbmUtaGVpZ2h0OjEuNDI4NTc7d29yZC1icmVh azpub3JtYWw7d29yZC13cmFwOm5vcm1hbDtib3JkZXI6MHB4IG5vbmUgYmxhY2s7Ym9yZGVy LXJhZGl1czo0cHg7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxwcmUgY2xhc3M9ImdtYWlsLW5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdp bi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPiJVc2Ugb2Ygd3JpdHRlbiBtb2RhbGl0 eSBpbiBhbm90aGVyIG1lZGlhIHN0cmVhbSB0aGFuIDwvcHJlPjxwcmUgY2xhc3M9ImdtYWls LXdvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O292ZXJmbG93OmF1dG87 Zm9udC1mYW1pbHk6TWVubG8sTW9uYWNvLENvbnNvbGFzLCZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LG1vbm9zcGFjZTtwYWRkaW5nOjBweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9t OjEwcHg7bGluZS1oZWlnaHQ6MS40Mjg1Nzt3b3JkLWJyZWFrOm5vcm1hbDt3b3JkLXdyYXA6 bm9ybWFsO2JvcmRlcjowcHggbm9uZSBibGFjaztib3JkZXItcmFkaXVzOjRweDt3aGl0ZS1z cGFjZTpwcmUtd3JhcCI+InRleHQiLCBtYXkgYmUgZGlzY3JpbWluYXRlZCBieSB1c2Ugb2Yg YSBzY3JpcHQgc3VidGFnIGluIHRoZSBsYW5ndWFnZSANCnRhZywgd2hlcmUgdGhhdCBpcyBh cHByb3ByaWF0ZS4iPC9wcmU+PHByZSBjbGFzcz0iZ21haWwtd29yZHdyYXAiIHN0eWxlPSJi b3gtc2l6aW5nOmJvcmRlci1ib3g7b3ZlcmZsb3c6YXV0bztmb250LWZhbWlseTpNZW5sbyxN b25hY28sQ29uc29sYXMsJnF1b3Q7Q291cmllciBOZXcmcXVvdDssbW9ub3NwYWNlO3BhZGRp bmc6MHB4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MTBweDtsaW5lLWhlaWdodDox LjQyODU3O3dvcmQtYnJlYWs6bm9ybWFsO3dvcmQtd3JhcDpub3JtYWw7Ym9yZGVyOjBweCBu b25lIGJsYWNrO2JvcmRlci1yYWRpdXM6NHB4O3doaXRlLXNwYWNlOnByZS13cmFwIj5bQkFd IFdoYXQgaWYgdGhlIGxhbmd1YWdlIGluIHF1ZXN0aW9uIGhhcyBzY3JpcHQgc3VidGFncyBz dXBwcmVzc2VkPyBXaGF0IGlmIHRoZSBPZmZlcmVyIGluY2x1ZGVzIGEgc2NyaXB0IHN1YnRh ZyBpbiB0aGUgdmlkZW8gbS1saW5lIGJ1dCBhbHNvICJzcGVha2VyIiBpbiB0aGUgQ29udGVu dCBhdHRyaWJ1dGU/IEFnYWluLCB0aGVyZSBjb3VsZCBiZSBxdWl0ZSBhIGZldyBjb3JuZXIg Y2FzZXMgbHVya2luZyBoZXJlLjwvcHJlPjwvcHJlPjwvcHJlPg0KICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9kaXY+DQog ICAgPC9ibG9ja3F1b3RlPg0KICAgICZsdDtHSCZndDsgVGhlIGFwcGxpY2F0aW9uIG11c3Qg bm90IGNyZWF0ZSBpbGxvZ2ljYWwgY29tYmluYXRpb25zLg0KICAgIEJ1dCBsZXQgdXMgZHJv cCB0aGUgIkNvbnRlbnQiIGF0dHJpYnV0ZSBoaW50LiBJIGZpbmQgdGhlIHVzZSBvZiB0aGUN CiAgICBzY3JpcHQgc3VidGFnIG11Y2ggbW9yZSBzb2xpZCBmb3IgdGhlIG90aGVyd2lzZSBh bWJpZ3VvdXMgY2FzZXMuIFJGQw0KICAgIDU2NDYgY2xlYXJseSBzYXlzIHRoYXQgaXQgaXMg YWxsb3dlZCB0byB1c2UgZXZlbiBzdXBwcmVzc2VkIHNjcmlwdA0KICAgIHN1YnRhZ3Mgd2hl biBpdHMgdXNlIGhhcyBhbiBpbXBvcnRhbnQgZGlzY3JpbWluYXRpbmcgbWVhbmluZy4NCiAg ICAoU2VjdGlvbiA0LjEgb2YgUkZDIDU2NDYgc2F5czoNCiAgICA8cHJlIGNsYXNzPSJuZXdw YWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7Ij4g ICAgICAgIlRoZSBzY3JpcHQgc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBmb3JtIGxh bmd1YWdlIHRhZ3MgdW5sZXNzDQogICAgICAgdGhlIHNjcmlwdCBhZGRzIHNvbWUgZGlzdGlu Z3Vpc2hpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRhZy4iPC9wcmU+DQogICAgVGhhdCBpcyB0 cnVlIGZvciBvdXIgY2FzZS4gVGhlIHByb2JsZW0gaXMgdGhhdCB3ZSBoYXZlIGhhZA0KICAg IHBlcnNpc3RlbnQgcmVzaXN0YW5jZSBmcm9tIHRoZSBsYW5ndWFnZSBleHBlcnRzIGZvciBi b3RoIHVzaW5nDQogICAgc3VwcHJlc3NlZCBzY3JpcHQgc3Vic3RhZ3MgZm9yIHdyaXR0ZW4g bW9kYWxpdHkgYW5kIHVzaW5nIHRoZSAtWnh4eA0KICAgIHNjcmlwdCBzdWJ0YWcgZm9yIHNw b2tlbiBtb2RhbGl0eS7CoCBDYW4gd2UgZXhwbGFpbiBvdXIgY2FzZSBiZXR0ZXINCiAgICBh bmQgZ2V0IGEgZ28gYWhlYWQgZnJvbSB0aGUgbGFuZ3VhZ2UgZXhwZXJ0cz8gVGhhdCB3b3Vs ZCByZXN1bHQgaW4gYQ0KICAgIHJlYWxseSBzaW1wbGUgc2V0IG9mIHJ1bGVzLiA8YnI+DQog ICAgPGJyPg0KICAgIEd1bm5hcjxicj4NCiAgICA8YnI+DQogICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSINCmNpdGU9Im1pZDpDQU9XKzJkdXE5cWtYQnk4UythX0dTcG1Qd3lwTUdMZllM M1Y5Wlpma3JEcmFTQStTMXdAbWFpbC5nbWFpbC5jb20iPg0KICAgICAgPGRpdiBkaXI9Imx0 ciI+DQogICAgICAgIDxkaXY+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgIDxkaXY+ DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLXdvcmR3cmFwIiBzdHlsZT0iYm94 LXNpemluZzpib3JkZXItYm94O292ZXJmbG93OmF1dG87Zm9udC1mYW1pbHk6TWVubG8sTW9u YWNvLENvbnNvbGFzLCZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LG1vbm9zcGFjZTtmb250LXNp emU6MTNweDtwYWRkaW5nOjBweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjEwcHg7 bGluZS1oZWlnaHQ6MS40Mjg1Nzt3b3JkLWJyZWFrOm5vcm1hbDt3b3JkLXdyYXA6bm9ybWFs O2NvbG9yOnJnYig1MSw1MSw1MSk7Ym9yZGVyOjBweCBub25lIGJsYWNrO2JvcmRlci1yYWRp dXM6NHB4O3doaXRlLXNwYWNlOnByZS13cmFwIj48cHJlIGNsYXNzPSJnbWFpbC13b3Jkd3Jh cCIgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveDtvdmVyZmxvdzphdXRvO2ZvbnQtZmFt aWx5Ok1lbmxvLE1vbmFjbyxDb25zb2xhcywmcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxtb25v c3BhY2U7cGFkZGluZzowcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbToxMHB4O2xp bmUtaGVpZ2h0OjEuNDI4NTc7d29yZC1icmVhazpub3JtYWw7d29yZC13cmFwOm5vcm1hbDti b3JkZXI6MHB4IG5vbmUgYmxhY2s7Ym9yZGVyLXJhZGl1czo0cHg7d2hpdGUtc3BhY2U6cHJl LXdyYXAiPjxwcmUgY2xhc3M9ImdtYWlsLXdvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzpi b3JkZXItYm94O292ZXJmbG93OmF1dG87Zm9udC1mYW1pbHk6TWVubG8sTW9uYWNvLENvbnNv bGFzLCZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LG1vbm9zcGFjZTtwYWRkaW5nOjBweDttYXJn aW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjEwcHg7bGluZS1oZWlnaHQ6MS40Mjg1Nzt3b3Jk LWJyZWFrOm5vcm1hbDt3b3JkLXdyYXA6bm9ybWFsO2JvcmRlcjowcHggbm9uZSBibGFjazti b3JkZXItcmFkaXVzOjRweDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+IDwvcHJlPjwvcHJlPjwv cHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0i Zm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtj b2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJn bWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBw eDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAgICAg ICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEz LjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCww LDApIj4NCjwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdl IiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90 dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAgICAgICAgICAgICA8cHJl IGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJn aW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJl Pg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9u dC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xv cjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFp bC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDtt YXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAgICAgICAg ICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMz MzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDAp Ij48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNw eDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+DQo8L3ByZT48L3ByZT4NCiAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAg ICAgIDwvZGl2Pg0KICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCiAgICAg ICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFNhdCwgTm92IDE4LCAyMDE3IGF0IDI6 MzMgUE0sIEd1bm5hcg0KICAgICAgICAgIEhlbGxzdHLDtm0gPHNwYW4gZGlyPSJsdHIiPiZs dDs8YQ0KICAgICAgICAgICAgICBocmVmPSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5p dG9yLnNlIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+Jmd0Ozwvc3Bhbj4NCiAg ICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwDQogICAgICAgICAgICAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgPGRp diB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4gVGhhbmtzIEJlcm5hcmQgZm9y DQogICAgICAgICAgICAgIHB1c2hpbmcgZm9yIGNsb3NpbmcgdGhlIGxhc3Qgb3BlbiBpc3N1 ZS4gPGJyPg0KICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgY2xh c3M9Img1Ij4gRGVuIDIwMTctMTEtMTgga2wuIDE5OjQ2LCBza3JldiBCZXJuYXJkDQogICAg ICAgICAgICAgICAgICBBYm9iYTo8YnI+DQogICAgICAgICAgICAgICAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+QXQg dGhpcyBwb2ludCwgb25seSBhIHNpbmdsZSBJc3N1ZQ0KICAgICAgICAgICAgICAgICAgICAg ICg0MykgcmVtYWlucyBvcGVuIG9uIGRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy08d2Jy Pmh1bWFuLWxhbmd1YWdlOjrCoA0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGENCiAg ICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvc2xpbS90aWNrZXQvNDMiDQogICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0i X2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjLzx3YnI+c2xpbS90aWNrZXQvNDM8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhpcyByZWxh dGVzIHRvIHRoZSBtb2RhbGl0eSBvZiBhIGxhbmd1YWdlDQogICAgICAgICAgICAgICAgICAg ICAgICBpbmRpY2F0aW9uLsKgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgPGRpdj5DdXJyZW50bHksIEd1bm5hciBoYXMgc3VnZ2VzdGVkIGENCiAgICAgICAgICAg ICAgICAgICAgICAgIG1vZGlmaWNhdGlvbiB0byB0aGUgdGV4dCBvZiBTZWN0aW9uIDUuNCBp biBvcmRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgdG8gYWRkcmVzcyB0aGUgaXNzdWU6 wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PjxhDQpocmVmPSJodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NsaW0vQTRiNldwZ2gwWjB6cFhLcXB3 RjliZmRXMzVnIg0KICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnLzx3 YnI+YXJjaC9tc2cvc2xpbS88d2JyPkE0YjZXcGdoMFowenBYS3Fwd0Y5YmZkVzM1ZzwvYT48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgPGRpdj5DYW4gV0cgcGFydGljaXBhbnRzIHJldmlldyB0 aGlzIHN1Z2dlc3RlZA0KICAgICAgICAgICAgICAgICAgICAgICAgY2hhbmdlLCBzbyB0aGF0 IHdlIGNhbiBkZXRlcm1pbmUgaG93IHRvIG1vdmUNCiAgICAgICAgICAgICAgICAgICAgICAg IGZvcndhcmQ/wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2 PkN1cnJlbnRseSwgU2VjdGlvbiA1LjQgc3RhdGVzIHRoYXQ6wqA8L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg PHByZSBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTt3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+ICAgVGhlIHByb2JsZW0gb2Yga25vd2luZyB3aGljaCBsYW5n dWFnZSB0YWdzIGFyZSBzaWduZWQgYW5kIHdoaWNoIGFyZQ0KICAgbm90IGlzIG91dCBvZiBz Y29wZSBvZiB0aGlzIGRvY3VtZW50LjwvcHJlPg0KICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwv YmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICAgIEkgZWFybGllciB0aG91Z2h0IHRoYXQgYW4gYXBwbGljYXRp b24gbmVlZGVkIHRvIGxvb2sgaW50bw0KICAgICAgICAgICAgICB0aGUgbGFuZ3VhZ2Ugc3Vi dGFnIERlc2NyaXB0aW9uIHRvIGZpbmQgdGhlIHdvcmQgInNpZ24iDQogICAgICAgICAgICAg IHRoZXJlIGluIHRoZSB0ZXh0IHN0cmluZy4gVGhhdCBpcyBub3QgYSBnb29kIHNvbHV0aW9u LiBCdXQNCiAgICAgICAgICAgICAgd2hlbiBzdHVkeWluZyB0aGUgdG9waWMgYWdhaW4gaW4g UkZDIDU2NDYgSSBmb3VuZCB0aGF0DQogICAgICAgICAgICAgIHRoZXJlIGlzIGEgY29uc2lz dGVudCBtYWNoaW5lLWltcGxlbWVudGFibGUgd2F5IHRvIGFzc2Vzcw0KICAgICAgICAgICAg ICBpZiBhIGxhbmd1YWdlIHN1YnRhZyBpcyBmb3IgYSBzaWduIGxhbmd1YWdlLiA8YnI+DQog ICAgICAgICAgICAgIFRoZXJlZm9yZSBJIGluY2x1ZGVkIHRoaXMgdGV4dCBpbiB0aGUgbGF0 ZXN0IHByb3Bvc2FsIGZvcg0KICAgICAgICAgICAgICBzZWN0aW9uIDUuNCBhdCB0aGUgbGlu ayB0aGF0IEJlcm5hcmQgcHJvdmlkZWQ6PGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAg ICAgICAgICAgICINCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0ibV8xOTEwNzIwNDA4MDQw MDc3Mzcxd29yZHdyYXAiIHN0eWxlPSJib3gtc2l6aW5nOmJvcmRlci1ib3g7b3ZlcmZsb3c6 YXV0bztmb250LWZhbWlseTpNZW5sbyxNb25hY28sQ29uc29sYXMsJnF1b3Q7Q291cmllciBO ZXcmcXVvdDssbW9ub3NwYWNlO2ZvbnQtc2l6ZToxM3B4O2Rpc3BsYXk6YmxvY2s7cGFkZGlu ZzowcHg7bWFyZ2luOjBweCAwcHggMTBweDtsaW5lLWhlaWdodDoxLjQyODU3O3dvcmQtYnJl YWs6bm9ybWFsO3dvcmQtd3JhcDpub3JtYWw7Y29sb3I6cmdiKDUxLDUxLDUxKTtiYWNrZ3Jv dW5kLWNvbG9yOndoaXRlO2JvcmRlcjowcHggbm9uZSBibGFjaztib3JkZXItcmFkaXVzOjRw eDt3aGl0ZS1zcGFjZTpwcmUtd3JhcDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQt bGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 NDAwO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0 aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiPkEgc3Bl Y2lmaWMgc2lnbiBsYW5ndWFnZSBjYW4gYmUgaWRlbnRpZmllZCBieSBpdHMgZXhpc3RlbmNl IGluIHRoZSBJQU5BIA0KcmVnaXN0cnkgb2YgbGFuZ3VhZ2Ugc3VidGFncyBhY2NvcmRpbmcg dG8gQkNQIDQ3IFtSRkM1NjQ2XSAsIGFuZCBmaW5kaW5nIA0KdGhhdCB0aGUgbGFuZ3VhZ2Ug c3VidGFnIGlzIGZvdW5kIGF0IGxlYXN0IGluIHR3byBlbnRyaWVzIGluIHRoZSANCnJlZ2lz dHJ5LCBvbmNlIHdpdGggdGhlIFR5cGUgZmllbGQgImxhbmd1YWdlIiBhbmQgb25jZSB3aXRo IHRoZSBUeXBlIA0KZmllbGQgImV4dGxhbmciIGNvbWJpbmVkIHdpdGggdGhlIFByZWZpeCBm aWVsZCB2YWx1ZSAic2duIi48L3ByZT4NCiAgICAgICAgICAgICAgIjxicj4NCiAgICAgICAg ICAgICAgPGJyPg0KICAgICAgICAgICAgICBTbyB0aGF0IHNob3VsZCBiZSB0aGUgcmVzcG9u c2Ugb24gRGFsZXMgcmVxdWVzdCB0byBlYXNpbHkNCiAgICAgICAgICAgICAgZGVjaWRlIGlm IGEgbGFuZ3VhZ2UgdGFnIGlzIGZvciBhIHNpZ24gbGFuZ3VhZ2UuIDxicj4NCiAgICAgICAg ICAgICAgPGJyPg0KICAgICAgICAgICAgICBXb3JzZSBpcyBuZXh0IHRvcGljIGluIGlzc3Vl IDQzOiB0byBhc3Nlc3MgaWYgYSBsYW5ndWFnZQ0KICAgICAgICAgICAgICB0YWcgaXMgZm9y IGEgc3Bva2VuIG1vZGFsaXR5IG9yIHdyaXR0ZW4gbW9kYWxpdHkgb2YgYQ0KICAgICAgICAg ICAgICBsYW5ndWFnZS48YnI+DQogICAgICAgICAgICAgIE15IHdvcmRpbmcgcHJvcG9zYWwg c3RhcnRzIHdpdGggdGhlIG9idmlvdXMgY2FzZXM6IGENCiAgICAgICAgICAgICAgbm9uLXNp Z25lZCBsYW5ndWdlIHRhZyBpbiBhdWRpbyBtZWRpYSBpcyBzcG9rZW4sIGFuZCBhDQogICAg ICAgICAgICAgIG5vbi1zaWduZWQgbGFuZ3VhZ2UgdGFnIGluIHRleHQgbWVkaWEgaXMgd3Jp dHRlbi7CoCBCdXQgZm9yDQogICAgICAgICAgICAgIG90aGVyIGNhc2VzLCBsaWtlIGluIHZp ZGVvIG9yIG1lc3NhZ2Ugb3IgYXBwbGljYXRpb24gb3INCiAgICAgICAgICAgICAgbXVsdGlw bGV4ZWQgbWVkaWEsIG90aGVyIGluZGljYXRpb25zIG11c3QgYmUgdXNlZCB0bw0KICAgICAg ICAgICAgICB1bmRlcnN0YW5kIHRoZSBpbnRlbmRlZCBtb2RhbGl0eS4gVGhlIHByb3Bvc2Vk IHRleHQNCiAgICAgICAgICAgICAgbWVudGlvbnMgYSBmZXcsIGFuZCBsZWF2ZXMgdG8gYXBw bGljYXRpb25zIHRvIGRlY2lkZSB3aGljaA0KICAgICAgICAgICAgICBtZWNoYW5pc21zIHRv IHVzZSBmb3Igc3VjaCBjYXNlcy4gSSB3aXNoIHdlIGZvciB0aGUNCiAgICAgICAgICAgICAg YW1iaWd1b3VzIGNhc2VzIGNvdWxkIHVzZSB0aGUgc2NyaXB0IHN1YnRhZyAtenh4eCB0bw0K ICAgICAgICAgICAgICBpbmRpY2F0ZSBzcG9rZW4gbW9kYWxpdHkgYW5kIGEgcmVhbCBzY3Jp cHQgc3VidGFnIGV2ZW4gb24NCiAgICAgICAgICAgICAgbGFuZ3VhZ2Ugc3VidGFncyB3aGVy ZSBzY3JpcHQgc3VidGFncyBhcmUgc3VwcHJlc3NlZCwNCiAgICAgICAgICAgICAgYmVjYXVz ZSB0aGF0IHdvdWxkIHNhdGlzZnkgaXNzdWUgNDMgbmljZWx5IGFuZCBtYWtlDQogICAgICAg ICAgICAgIHNlY3Rpb24gNS40IG11Y2ggc2hvcnRlciBhbmQgY2xlYXJlci4gQnV0IHdlIGhh dmUgaGFkDQogICAgICAgICAgICAgIHJlc2lzdGFuY2UgYWdhaW5zdCB0aGF0IHNvbHV0aW9u LiA8YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgVGhlIHByb3Bvc2Vk IHRleHQgbWlnaHQgYmUgYSBiaXQgbG9uZyBhbmQgZGV0YWlsZWQuIEkgYW0NCiAgICAgICAg ICAgICAgcHJlcGFyZWQgdG8gYWdyZWUgb24gYSBzaG9ydGVuZWQgdmVyc2lvbiBpZiB0aGVy ZSBhcmUgYW55DQogICAgICAgICAgICAgIHByb3Bvc2Fscy4gSSB0aGluayB0aG91Z2ggdGhh dCBjb250ZW50cyBvZiA1LjQgaW4gdGhlDQogICAgICAgICAgICAgIGRpcmVjdGlvbiBvZiBt eSBwcm9wb3NhbCBpcyB3aGF0IHNhdGlzZmllc8KgIGlzc3VlIDQzIGFuZA0KICAgICAgICAg ICAgICBhbHNvIHRoZSBjb21tZW50cyBsYXRlbHkgdGhhdCBzZWN0aW9uIDUuNCBpcyB0b28N CiAgICAgICAgICAgICAgcmVzdHJpY3RpdmUuIDxicj4NCiAgICAgICAgICAgICAgPGJyPg0K ICAgICAgICAgICAgICAvR3VubmFyPGJyPg0KICAgICAgICAgICAgICDCoDxicj4NCiAgICAg ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICDCoA0KICAgICAgICAgICAgICA8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YnI+DQogICAgICAgICAgICAgICAgPGZpZWxkc2V0DQogICAg ICAgICAgICAgICAgICBjbGFzcz0ibV8xOTEwNzIwNDA4MDQwMDc3MzcxbWltZUF0dGFjaG1l bnRIZWFkZXIiPjwvZmllbGRzZXQ+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICAgIDxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19f X19fX19fX19fXw0KU0xJTSBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtXzE5MTA3MjA0MDgw NDAwNzczNzFtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpTTElNQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5TTElNQGll dGYub3JnPC9hPg0KPGEgY2xhc3M9Im1fMTkxMDcyMDQwODA0MDA3NzM3MW1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zbGltIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vc2xpbTwvYT48c3BhbiBjbGFz cz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8L2ZvbnQ+PC9zcGFuPjwvcHJl Pg0KICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIj ODg4ODg4Ij4gPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij4gPGJyPg0KICAgICAg ICAgICAgICAgICAgPHByZSBjbGFzcz0ibV8xOTEwNzIwNDA4MDQwMDc3MzcxbW96LXNpZ25h dHVyZSIgY29scz0iNzIiPi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdi cj4tLS0tLS0tLS0tLQ0KR3VubmFyIEhlbGxzdHLDtm0NCk9tbml0b3INCjxhIGNsYXNzPSJt XzE5MTA3MjA0MDgwNDAwNzczNzFtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiIHRhcmdldD0iX2JsYW5rIiBtb3ot ZG8tbm90LXNlbmQ9InRydWUiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT4NCis0 NiA3MDggMjA0IDI4ODwvcHJlPg0KICAgICAgICAgICAgICAgIDwvZm9udD48L3NwYW4+PC9k aXY+DQogICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGJyPg0KICAgICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8 cHJlIGNsYXNzPSJtb3otc2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KR3VubmFyIEhlbGxzdHLDtm0NCk9tbml0 b3INCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpn dW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5z ZTwvYT4NCis0NiA3MDggMjA0IDI4ODwvcHJlPg0KICA8L2JvZHk+DQo8L2h0bWw+DQo= --------------7EBCE60112A79A8F382445A8-- From nobody Sun Nov 19 09:27: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 DEFFC127011 for ; Sun, 19 Nov 2017 09:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cnfqJo8kY1wJ for ; Sun, 19 Nov 2017 09:27:48 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 54E001200E5 for ; Sun, 19 Nov 2017 09:27:48 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 70so5543914pgf.6 for ; Sun, 19 Nov 2017 09:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eWoLohJIRbaYaQKMGCLwTCbZzVDvX0Hc9kVNyiAJJmc=; b=KNqk2mzFbqw+GF6cJRHj+4N19oWZlyivDHUB6rIgBxyWEK1XIyqDOVlrz0m1BBdrUd F7FSExKdvRKmz3R/F0J1Hg4DdZt5V+3lEvdUKPPk37P/QZ1x8CrOpRs8Eex+INzpy6jn fOkeb4Cz4mj6oqKUGV1LE2S9CtJWqaQ/df+C8XWi/NEyz6lyonVU/fDFDUyi73ou6jg2 EsuVLhUaV1r/nJ2BhN71VRJB6EzP96O4F770YLPW4e4mKR7760IG5DdZcQcG69/QScqc Eo0Grd1FzAzppFepQo5xjpYKzZyiZ6f7nog0Q2fMegKovMVk4WDwWfWhL1E5K8RurcQ9 cOPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eWoLohJIRbaYaQKMGCLwTCbZzVDvX0Hc9kVNyiAJJmc=; b=rJNYYvK2gquM/RRgfld9VYaKylfZ7skWu+6av7dOcDl3xR/ZlKd25+L3P7jNUldunu frd95xIzotzo+dFPAS8sUGTSp5dlAoDPxhBsVVhODBu4EudPXeXroZ83ZAU8KOAllHsE +UzQNt8tMjYSJslrEkskMt2eGStZie7ifYdxY8soMYKCqMa21byvg7fuR1QlqKC01eR4 Hj0x38tDxF3JQCUUmTTZYujumKVrmNYlwWN/73he+P9OBmH32fk5kAOBJU6YPC+XrOJI d/zmIft766HFdE8RHE9gAQDRGHnewAmmnlejNb76ZvAFlI1g8TFoHln6LgtbE/bkLwdy Csnw== X-Gm-Message-State: AJaThX4696rh3potvjul5KYp2YCqe/EJnx2FYYrV16TgAeTFJiO0wL2G 1PsML3cHj9e/lX2Frygu0QKpkSrf X-Google-Smtp-Source: AGs4zMYvZg3fjf15KZhjDhG/xCcxtDuNzdNDhomi4Ws2F6WDA6X8Nv+ZnO9GpZX9in6ex3y439ZRhg== X-Received: by 10.99.112.66 with SMTP id a2mr10891591pgn.157.1511112467192; Sun, 19 Nov 2017 09:27:47 -0800 (PST) Received: from [10.170.101.184] (mobile-166-176-185-60.mycingular.net. [166.176.185.60]) by smtp.gmail.com with ESMTPSA id o88sm15541022pfj.175.2017.11.19.09.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 09:27:46 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-B06DE79F-4AB8-4752-BE20-F4C156C1F7EE Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15B150) In-Reply-To: <7cf08f46-af12-a18b-b9e0-a0b14be7c816@omnitor.se> Date: Sun, 19 Nov 2017 09:27:45 -0800 Cc: slim@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se> <7cf08f46-af12-a18b-b9e0-a0b14be7c816@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language 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: Sun, 19 Nov 2017 17:27:50 -0000 --Apple-Mail-B06DE79F-4AB8-4752-BE20-F4C156C1F7EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 19, 2017, at 2:40 AM, Gunnar Hellstr=C3=B6m wrote: >> Yes, it is a SHOULD. But all registered sign languages so >> far follow this rule, so I think it is solid. Do you think we need >> to weaken the start of our recommended procedure:=20 [BA] As you say, it does appear that the rule is being followed. But perhaps= we can find an expert to confirm this. > Among the three obvious cases are also that sign languages in video me= dia are signed. [BA] Yes. > The application must not create illogical combinations. But let us dr= op the "Content" attribute hint. I find the use of the script subtag much mo= re solid for the otherwise ambiguous cases. RFC 5646 clearly says that it is= allowed to use even suppressed script subtags when its use has an important= discriminating meaning. (Section 4.1 of RFC 5646 says: > "The script subtag SHOULD NOT be used to form language tags unless > the script adds some distinguishing information to the tag." > That is true for our case.=20 > Can we explain our case better and get a go ahead from the language expert= s? That would result in a really simple set of rules.=20 [BA] It seems like an important point to clarify. Let me try to figure out h= ow we can get expert consultation. --Apple-Mail-B06DE79F-4AB8-4752-BE20-F4C156C1F7EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

<GH>Ye= s, it is a SHOULD. But all registered sign languages so
far follow this r= ule, so I think it is solid. Do you think we need to weaken the start of our recommended procedure: 

[BA] As you say, it does appear th= at the rule is being followed. But perhaps we can find an expert to confirm t= his.


            

          

        

      

    

    <GH>Among the three obvious cases are also that sign languages
    in video media are signed.

[BA] Yes.

<=
blockquote type=3D"cite">

            

          

        

      
    

    <GH> The application must not create illogical combinations.
    But let us drop the "Content" attribute hint. I find the use of the
    script subtag much more solid for the otherwise ambiguous cases. RFC
    5646 clearly says that it is allowed to use even suppressed script
    subtags when its use has an important discriminating meaning.
    (Section 4.1 of RFC 5646 says:
    
  =
     "The script subtag SHOULD NOT be used to form language tags unless
       the script adds some distinguishing information to the tag."

    That is true for our case. 
C=
an we explain our case better
    and get a go ahead from the language experts? That would result in a
    really simple set of rules. 

[BA] It seem=
s like an important point to clarify.  Let me try to figure out how we c=
an get expert consultation.
=

--Apple-Mail-B06DE79F-4AB8-4752-BE20-F4C156C1F7EE--


From nobody Sun Nov 19 15:07:52 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 47BA31200B9 for ; Sun, 19 Nov 2017 15:07:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.919
X-Spam-Level: 
X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52drv95VZylk for ; Sun, 19 Nov 2017 15:07:46 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3977512009C for ; Sun, 19 Nov 2017 15:07:46 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.44,423,1505779200";  d="scan'208,217";a="662872309"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  19 Nov 2017 23:07:28 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id vAJN7Npk126011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 19 Nov 2017 23:07:24 GMT
Received: from EX13D08UWB004.ant.amazon.com (10.43.161.232) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Sun, 19 Nov 2017 23:07:23 +0000
Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by EX13D08UWB004.ant.amazon.com (10.43.161.232) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Sun, 19 Nov 2017 23:07:23 +0000
Received: from EX13D08UWB002.ant.amazon.com ([10.43.161.168]) by EX13D08UWB002.ant.amazon.com ([10.43.161.168]) with mapi id 15.00.1236.000; Sun, 19 Nov 2017 23:07:23 +0000
From: "Phillips, Addison" 
To: Bernard Aboba , =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= 
CC: "slim@ietf.org" 
Thread-Topic: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
Thread-Index: AQHTYJ2lgFSz4ObNVkeN4ZgI9lM9A6MauTKAgABzB4CAASVlQA==
Date: Sun, 19 Nov 2017 23:07:23 +0000
Message-ID: 
References:  <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.161.100]
Content-Type: multipart/alternative; boundary="_000_f75ade4b0f3740c9af26ec274e9857e1EX13D08UWB002antamazonc_"
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Sun, 19 Nov 2017 23:07:50 -0000

--_000_f75ade4b0f3740c9af26ec274e9857e1EX13D08UWB002antamazonc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QSBmZXcgcG9pbnRzLg0KDQoNCjEuICAgICAgIFNpZ24gbGFuZ3VhZ2VzIGRvIG5vdCBuZWNlc3Nh
cmlseSB1c2UgdGhlIHN1YnRhZyDigJhzZ27igJkuIEluIGZhY3QsIG1vc3Qgc2lnbiBsYW5ndWFn
ZXMgaGF2ZSBzdWJ0YWdzIHRoYXQgaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggdGhlIOKAmHNnbuKA
mSBzdWJ0YWcuIFRoZXkgYXJlIG5vdCDigJhleHRsYW5n4oCZIGFuZCBkbyBub3QgaGF2ZSBhIG1h
Y3JvbGFuZ3VhZ2Ugb2Yg4oCYc2du4oCZLiBGb3IgZXhhbXBsZSwgaGVyZSBpcyB0aGUgcmVjb3Jk
IGZvciBBbWVyaWNhbiBTaWduIExhbmd1YWdlOg0KDQolJQ0KVHlwZTogbGFuZ3VhZ2UNClN1YnRh
ZzogYXNlDQpEZXNjcmlwdGlvbjogQW1lcmljYW4gU2lnbiBMYW5ndWFnZQ0KQWRkZWQ6IDIwMDkt
MDctMjkNCiUlDQoNCg0KDQoyLiAgICAgICBTaWduIGxhbmd1YWdlcyBtYXkgaGF2ZSB0aGUgd29y
ZHMg4oCcU2lnbiBMYW5ndWFnZeKAnSBpbiBvbmUgb2YgdGhlaXIgRGVzY3JpcHRpb24gZmllbGRz
IChub3RpY2UgdGhhdCBJIHNheSDigJxvbmUgb2bigJ0pLiBJ4oCZbSBub3Qgc3VyZSB0aGF0IGFs
bCBzaWduIGxhbmd1YWdlcyBoYXZlIHRoaXMuIFNvbWVvbmUgd291bGQgaGF2ZSB0byBhc2sgdGhl
IElTTyA2MzkgZm9sa3MgaWYgdGhlcmUgYXJlIGFueSBvdXRsaWVycy4NCg0KMy4gICAgICAgU3Vw
cHJlc3MtU2NyaXB0IGlzIGFuIGFkdmlzb3J5IGZpZWxkIGluIHRoZSByZWdpc3RyeS4gSXQgZG9l
cyBub3QgY2F1c2Ugb3IgcmVxdWlyZSB0aGF0IHRoZSBzY3JpcHQgc3VidGFnIGJlIG9taXR0ZWQu
IEl0IGlzIGFsc28gYW4gaW5jb21wbGV0ZSBiaXQgb2YgZG9jdW1lbnRhdGlvbjogbWFueSBsYW5n
dWFnZXMgdGhhdCBmaXQgdGhlIGNyaXRlcmlhIGZvciBTdXBwcmVzcy1TY3JpcHQgZG8gbm90IGhh
dmUgdGhlIGZpZWxkIGluIHRoZSByZWdpc3RyeS4gVXNlIG9yIG5vbi11c2Ugb2YgdGhlIHNjcmlw
dCBzdWJ0YWcgaXMgbm90IGEgdmVyeSByZWxpYWJsZSBpbmRpY2F0b3Igb2YgbGFuZ3VhZ2UgbW9k
YWxpdHkgb24gaXRzIG93bi4gVGFncyBsaWtlIOKAnGVuLVVT4oCdIG9yIOKAnGRl4oCdIGZ1bmN0
aW9uIHdlbGwgZm9yIGlkZW50aWZ5aW5nIHRoZSBsYW5ndWFnZSBvZiB2YXJpb3VzIG1hdGVyaWFs
cyBhbmQgSSBjYXV0aW9uIGZvbGtzIHRoYXQsIGluIG15IGV4cGVyaWVuY2UsIGFyY2FuZSBydWxl
cyBhYm91dCB0aGUgc3BlY2lhbGl6ZWQgdXNlIG9mIHN1YnRhZ3MgYXJlIGxpa2VseSB0byBiZSBp
Z25vcmVkLg0KDQpPdmVyYWxsLCBteSBzdWdnZXN0aW9uIHdvdWxkIGJlOiBpZiB5b3UgbmVlZCB0
byBkZWFsIHdpdGggbW9kYWxpdHksIGRvbuKAmXQgdXNlIChleGlzdGluZykgbGFuZ3VhZ2Ugc3Vi
dGFncyBmb3IgaXQuIEVuY29kZSBtZXRhZGF0YSB0byBtYWtlIHRoaW5ncyBleHBsaWNpdC4gVXNl
IHByaXZhdGUgdXNlIHN1YnRhZ3Mgb3IgYW4gZXh0ZW5zaW9uIGZvciBpdCBpZiB5b3UgbXVzdC4g
QnV0IGRvbuKAmXQgcHJvdmlkZSBzdXBlci1zcGVjaWFsIG1lYW5pbmcgZm9yIHN1YnRhZ3MuIFBl
cnNvbmFsbHksIEkgdGVuZCB0byB0aGluayB5b3Ugc2hvdWxkIGVuY29kZSBtb2RhbGl0eSBvbiBh
IGRpZmZlcmVudCBsZXZlbC4gU29tZW9uZSB3aG8gaXMgaGFyZCBvZiBoZWFyaW5nIGFuZCBsb3cg
dmlzaW9uIGhhcyBkaWZmZXJlbnQgbmVlZHMgZnJvbSBhIGJsaW5kIHVzZXIgd2hvIGhhcyBkaWZm
ZXJlbnQgbmVlZHMgZnJvbSBhIGRlYWYgcGVyc29uIHdpdGggbGltaXRlZCBtb2JpbGl0eeKApiBl
dGMuDQoNCkFkZGlzb24NCg0KRnJvbTogU0xJTSBbbWFpbHRvOnNsaW0tYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIEJlcm5hcmQgQWJvYmENClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAx
OCwgMjAxNyA5OjI1IFBNDQpUbzogR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5oZWxsc3Ryb21A
b21uaXRvci5zZT4NCkNjOiBzbGltQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NsaW1dIE1vdmlu
ZyBmb3J3YXJkIG9uIGRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZQ0K
DQpHdW5uYXIgc2FpZDoNCg0KIkkgZWFybGllciB0aG91Z2h0IHRoYXQgYW4gYXBwbGljYXRpb24g
bmVlZGVkIHRvIGxvb2sgaW50byB0aGUgbGFuZ3VhZ2Ugc3VidGFnIERlc2NyaXB0aW9uIHRvIGZp
bmQgdGhlIHdvcmQgInNpZ24iIHRoZXJlIGluIHRoZSB0ZXh0IHN0cmluZy4gVGhhdCBpcyBub3Qg
YSBnb29kIHNvbHV0aW9uLiINCg0KW0JBXSBBZ3JlZWQuIEFsc28sIGFzIGluZGljYXRlZCBpbiBS
RkMgNTY0NiBTZWN0aW9uIDQuMS4yIGFuZCB0aGUgSUFOQSByZWdpc3RyeSAoaHR0cHM6Ly93d3cu
aWFuYS5vcmcvYXNzaWdubWVudHMvbGFuZ3VhZ2Utc3VidGFnLXJlZ2lzdHJ5L2xhbmd1YWdlLXN1
YnRhZy1yZWdpc3RyeSksIHNpZ24gbGFuZ3VhZ2VzIG1heSBub3QgaGF2ZSBhbHdheXMgaGF2ZSBh
IHN1YnRhZyBvZiAnc2duJzoNCg0KDQogICBTaWduIGxhbmd1YWdlcyBzaGFyZSBhIG1vZGUgb2Yg
Y29tbXVuaWNhdGlvbiByYXRoZXIgdGhhbiBhIGxpbmd1aXN0aWMNCg0KICAgaGVyaXRhZ2UuICBU
aGVyZSBhcmUgbWFueSBzaWduIGxhbmd1YWdlcyB0aGF0IGhhdmUgZGV2ZWxvcGVkDQoNCiAgIGlu
ZGVwZW5kZW50bHksIGFuZCB0aGUgc3VidGFnICdzZ24nIGluZGljYXRlcyBvbmx5IHRoZSBwcmVz
ZW5jZSBvZiBhDQoNCiAgIHNpZ24gbGFuZ3VhZ2UuICBBIG51bWJlciBvZiBzaWduIGxhbmd1YWdl
cyBhbHNvIGhhZCBncmFuZGZhdGhlcmVkDQoNCiAgIHRhZ3MgcmVnaXN0ZXJlZCBmb3IgdGhlbSBk
dXJpbmcgdGhlIFJGQyAzMDY2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMDY2PiBl
cmEuICBGb3IgZXhhbXBsZSwgdGhlDQoNCiAgIGdyYW5kZmF0aGVyZWQgdGFnICJzZ24tVVMiIHdh
cyByZWdpc3RlcmVkIHRvIHJlcHJlc2VudCAnQW1lcmljYW4gU2lnbg0KDQogICBMYW5ndWFnZScg
c3BlY2lmaWNhbGx5LCB3aXRob3V0IHJlZmVyZW5jZSB0byB0aGUgVW5pdGVkIFN0YXRlcy4gIFRo
aXMNCg0KICAgaXMgc3RpbGwgdmFsaWQsIGJ1dCBkZXByZWNhdGVkOiBhIGRvY3VtZW50IGluIEFt
ZXJpY2FuIFNpZ24gTGFuZ3VhZ2UNCg0KICAgY2FuIGJlIGxhYmVsZWQgZWl0aGVyICJhc2UiIG9y
ICJzZ24tYXNlIiAodGhlICdhc2UnIHN1YnRhZyBpcyBmb3IgdGhlDQoNCiAgIGxhbmd1YWdlIGNh
bGxlZCAnQW1lcmljYW4gU2lnbiBMYW5ndWFnZScpLg0KDQpHdW5uYXIgYWxzbyBzYWlkOg0KDQoN
CiJBIHNwZWNpZmljIHNpZ24gbGFuZ3VhZ2UgY2FuIGJlIGlkZW50aWZpZWQgYnkgaXRzIGV4aXN0
ZW5jZSBpbiB0aGUgSUFOQQ0KDQpyZWdpc3RyeSBvZiBsYW5ndWFnZSBzdWJ0YWdzIGFjY29yZGlu
ZyB0byBCQ1AgNDcgW1JGQzU2NDZdICwgYW5kIGZpbmRpbmcNCg0KdGhhdCB0aGUgbGFuZ3VhZ2Ug
c3VidGFnIGlzIGZvdW5kIGF0IGxlYXN0IGluIHR3byBlbnRyaWVzIGluIHRoZQ0KDQpyZWdpc3Ry
eSwgb25jZSB3aXRoIHRoZSBUeXBlIGZpZWxkICJsYW5ndWFnZSIgYW5kIG9uY2Ugd2l0aCB0aGUg
VHlwZQ0KDQpmaWVsZCAiZXh0bGFuZyIgY29tYmluZWQgd2l0aCB0aGUgUHJlZml4IGZpZWxkIHZh
bHVlICJzZ24iLg0KDQpTbyB0aGF0IHNob3VsZCBiZSB0aGUgcmVzcG9uc2Ugb24gRGFsZXMgcmVx
dWVzdCB0byBlYXNpbHkgZGVjaWRlIGlmIGEgbGFuZ3VhZ2UgdGFnIGlzIGZvciBhIHNpZ24gbGFu
Z3VhZ2UuICINCg0KW0JBXSAgTG9va2luZyBhdCB0aGUgSUFOQSByZWdpc3RyeSwgaGF2aW5nIGEg
VHlwZSBmaWVsZCAiZXh0bGFuZyIgY29tYmluZWQgd2l0aCB0aGUgUHJlZml4IGZpZWxkIHZhbHVl
ICdzZ24nIHNlZW1zIHRvIGJlIHVzZWQgYXMgYW4gaW5kaWNhdG9yIG9mIGEgc2lnbiBsYW5ndWFn
ZS4gIERvIHlvdSB0aGluayB3ZSBjYW4gcmVseSBvbiB0aGlzPyBDdXJyZW50bHkgdGhpcyBpcyBv
bmx5IGEgU0hPVUxEICBpbiBSRkMgNTY0NiBTZWN0aW9uIDMuNDoNCg0KDQogICAgICAgICAgICAz
LiAgU2lnbiBsYW5ndWFnZXMgU0hPVUxEIGhhdmUgYW4gJ2V4dGxhbmcnIHJlY29yZCB3aXRoIGFu
J1ByZWZpeCcgb2YgJ3NnbicuDQoNCg0KDQoNCg0KIk15IHdvcmRpbmcgcHJvcG9zYWwgc3RhcnRz
IHdpdGggdGhlIG9idmlvdXMgY2FzZXM6IGEgbm9uLXNpZ25lZCBsYW5ndWFnZSB0YWcgaW4gYXVk
aW8gbWVkaWEgaXMgc3Bva2VuLCBhbmQgYSBub24tc2lnbmVkIGxhbmd1YWdlIHRhZyBpbiB0ZXh0
IG1lZGlhIGlzIHdyaXR0ZW4uIg0KDQoNCg0KW0JBXSBBc3N1bWluZyB5b3VyIHN1Z2dlc3RlZCBh
cHByb2FjaCBhbGxvd3MgdXMgdG8gcmVsaWFibHkgZGV0ZXJtaW5lIG5vbi1zaWduIGxhbmd1YWdl
cywgdGhpcyBzZWVtcyBzb2xpZC4NCg0KDQoNCkd1bm5hciBmdXJ0aGVyIHNhaWQ6DQoNCg0KDQoi
QnV0IGZvciBvdGhlciBjYXNlcywgbGlrZSBpbiB2aWRlbyBvciBtZXNzYWdlIG9yIGFwcGxpY2F0
aW9uIG9yIG11bHRpcGxleGVkIG1lZGlhLCBvdGhlciBpbmRpY2F0aW9ucyBtdXN0IGJlIHVzZWQg
dG8NCg0KdW5kZXJzdGFuZCB0aGUgaW50ZW5kZWQgbW9kYWxpdHkuLi4gSSB3aXNoIGZvciB0aGUg
YW1iaWd1b3VzIGNhc2VzIHdlIGNvdWxkIHVzZSB0aGUgc2NyaXB0IHN1YnRhZyAtenh4eCB0byBp
bmRpY2F0ZQ0KDQpzcG9rZW4gbW9kYWxpdHkgYW5kIGEgcmVhbCBzY3JpcHQgc3VidGFnLi4uIg0K
DQoNCg0KW0JBXSBUaGlzIGlzIHdoZXJlIEkgYmVjb21lIHVuZWFzeSwgYmVjYXVzZSB3aXRob3V0
IGFuIGV4cGxpY2l0IG1lY2hhbmlzbSBzdWNoIGFzIHNjcmlwdCBzdWJ0YWdzLCB0aGVyZSBpcyB0
aGUgcG90ZW50aWFsIGZvciBhbWJpZ3VpdHkuDQoNClRyeWluZyB0byBhZGRyZXNzIHJlZHVjZSB0
aGF0IGFtYmlndWl0eSB2aWEgaGV1cmlzdGljcyBjb3VsZCB0dXJuIG91dCB0byBiZSBhIGJhZCBp
ZGVhLCBjb21wYXJlZCB3aXRoIHByb2NlZWRpbmcgbW9yZSBjYXV0aW91c2x5DQoNCmJ5IGxlYXZp
bmcgYmVoYXZpb3IgdW5kZWZpbmVkIGZvciBub3cgYW5kIHJldmlzaXRpbmcgdGhlIHNpdHVhdGlv
biBsYXRlciB3aGVuIHdlIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gYmV0dGVyLiBGb3IgZXhhbXBs
ZToNCg0KDQoNCiJVc2UgZm9yIHNlbmRpbmcgb2YgYSB2aXN1YWwgdmlldyBvZiBhIHNwZWFraW5n
IHBlcnNvbiBtYXkgYmUgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSAic3BlYWtlciIgaW4gYW4gU0RQ
DQoNCkNvbnRlbnQgYXR0cmlidXRlIGFjY29yZGluZyB0byBSRkMgNDc5NiBbUkZDNDc5Nl0gaW4g
YSAidmlkZW8iIG1lZGlhIHN0cmVhbSBvciBhbm90aGVyIG1lZGlhIGNhcnJ5aW5nIHZpZGVvIChl
LmcuICJtZXNzYWdlIiBvciAiYXBwbGljYXRpb24iKS4iDQoNCltCQV0gVGhlcmUgYXJlIHF1aXRl
IGEgZmV3IHBvdGVudGlhbCBjb3JuZXIgY2FzZXMgaGVyZS4gRm9yIGV4YW1wbGUsIGlmICJlbi1V
UyIgbGFuZ3VhZ2UgaXMgaW5jbHVkZWQgaW4gYW4gb2ZmZXIgd2l0aGluIGEgdmlkZW8gbS1saW5l
LCBzaG91bGQgdGhlIGFuc3dlcmVyIGFzc3VtZSB0aGlzIGltcGxpZXMgYSB3aWxsaW5nbmVzcyB0
byBsaXAgcmVhZCBVUyBFbmdsaXNoIGlmIHRoZSB2YWx1ZSAic3BlYWtlciIgaXMgaW4gdGhlIENv
bnRlbnQgYXR0cmlidXRlPyAgV2hhdCBjYW4gYmUgYXNzdW1lZCBpZiBhIHZhbHVlIG90aGVyIHRo
YW4gInNwZWFrZXIiIGlzIGluIHRoZSBDb250ZW50IGF0dHJpYnV0ZT8gTWlnaHQgdGhhdCByZXBy
ZXNlbnQgc29tZXRoaW5nIGVudGlyZWx5IGRpZmZlcmVudCwgc3VjaCBhcyB0aGUgZGVzaXJlIHRv
IHJlY2VpdmUgY2FwdGlvbmluZyBpbiBVUyBFbmdsaXNoPyBJZiBzbywgaG93IGNvdWxkIHRoZSBP
ZmZlcmVyIGluZGljYXRlIGJvdGggdGhlIGNhcGFiaWxpdHkgb2YgbGlwcmVhZGluZyBhbmQgdGhl
IGFiaWxpdHkgdG8gaGFuZGxlIGNhcHRpb25zPyBBbmQgd2hhdCBoYXBwZW5zIGlmIHRoZSBBbnN3
ZXJlciBkb2Vzbid0IG1pbWljIHRoZSBDb250ZW50IGF0dHJpYnV0ZSBpbiB0aGUgT2ZmZXI/IFNl
ZW1zIGxpa2UgdGhlcmUgYXJlIHNvbWUgcG90ZW50aWFsICJnb3RjaGFzIiBoZXJlLg0KDQoiVXNl
IG9mIHdyaXR0ZW4gbW9kYWxpdHkgaW4gYW5vdGhlciBtZWRpYSBzdHJlYW0gdGhhbg0KDQoidGV4
dCIsIG1heSBiZSBkaXNjcmltaW5hdGVkIGJ5IHVzZSBvZiBhIHNjcmlwdCBzdWJ0YWcgaW4gdGhl
IGxhbmd1YWdlDQoNCnRhZywgd2hlcmUgdGhhdCBpcyBhcHByb3ByaWF0ZS4iDQoNCltCQV0gV2hh
dCBpZiB0aGUgbGFuZ3VhZ2UgaW4gcXVlc3Rpb24gaGFzIHNjcmlwdCBzdWJ0YWdzIHN1cHByZXNz
ZWQ/IFdoYXQgaWYgdGhlIE9mZmVyZXIgaW5jbHVkZXMgYSBzY3JpcHQgc3VidGFnIGluIHRoZSB2
aWRlbyBtLWxpbmUgYnV0IGFsc28gInNwZWFrZXIiIGluIHRoZSBDb250ZW50IGF0dHJpYnV0ZT8g
QWdhaW4sIHRoZXJlIGNvdWxkIGJlIHF1aXRlIGEgZmV3IGNvcm5lciBjYXNlcyBsdXJraW5nIGhl
cmUuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gU2F0LCBOb3YgMTgsIDIw
MTcgYXQgMjozMyBQTSwgR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5oZWxsc3Ryb21Ab21uaXRv
ci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPj4gd3JvdGU6DQpUaGFua3Mg
QmVybmFyZCBmb3IgcHVzaGluZyBmb3IgY2xvc2luZyB0aGUgbGFzdCBvcGVuIGlzc3VlLg0KRGVu
IDIwMTctMTEtMTgga2wuIDE5OjQ2LCBza3JldiBCZXJuYXJkIEFib2JhOg0KDQpBdCB0aGlzIHBv
aW50LCBvbmx5IGEgc2luZ2xlIElzc3VlICg0MykgcmVtYWlucyBvcGVuIG9uIGRyYWZ0LWlldGYt
c2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZTo6DQpodHRwczovL3RyYWMuaWV0Zi5vcmcv
dHJhYy9zbGltL3RpY2tldC80Mw0KDQpUaGlzIHJlbGF0ZXMgdG8gdGhlIG1vZGFsaXR5IG9mIGEg
bGFuZ3VhZ2UgaW5kaWNhdGlvbi4NCg0KQ3VycmVudGx5LCBHdW5uYXIgaGFzIHN1Z2dlc3RlZCBh
IG1vZGlmaWNhdGlvbiB0byB0aGUgdGV4dCBvZiBTZWN0aW9uIDUuNCBpbiBvcmRlciB0byBhZGRy
ZXNzIHRoZSBpc3N1ZToNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2xp
bS9BNGI2V3BnaDBaMHpwWEtxcHdGOWJmZFczNWcNCg0KDQpDYW4gV0cgcGFydGljaXBhbnRzIHJl
dmlldyB0aGlzIHN1Z2dlc3RlZCBjaGFuZ2UsIHNvIHRoYXQgd2UgY2FuIGRldGVybWluZSBob3cg
dG8gbW92ZSBmb3J3YXJkPw0KDQpDdXJyZW50bHksIFNlY3Rpb24gNS40IHN0YXRlcyB0aGF0Og0K
DQoNCiAgIFRoZSBwcm9ibGVtIG9mIGtub3dpbmcgd2hpY2ggbGFuZ3VhZ2UgdGFncyBhcmUgc2ln
bmVkIGFuZCB3aGljaCBhcmUNCg0KICAgbm90IGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50Lg0KSSBlYXJsaWVyIHRob3VnaHQgdGhhdCBhbiBhcHBsaWNhdGlvbiBuZWVkZWQgdG8gbG9v
ayBpbnRvIHRoZSBsYW5ndWFnZSBzdWJ0YWcgRGVzY3JpcHRpb24gdG8gZmluZCB0aGUgd29yZCAi
c2lnbiIgdGhlcmUgaW4gdGhlIHRleHQgc3RyaW5nLiBUaGF0IGlzIG5vdCBhIGdvb2Qgc29sdXRp
b24uIEJ1dCB3aGVuIHN0dWR5aW5nIHRoZSB0b3BpYyBhZ2FpbiBpbiBSRkMgNTY0NiBJIGZvdW5k
IHRoYXQgdGhlcmUgaXMgYSBjb25zaXN0ZW50IG1hY2hpbmUtaW1wbGVtZW50YWJsZSB3YXkgdG8g
YXNzZXNzIGlmIGEgbGFuZ3VhZ2Ugc3VidGFnIGlzIGZvciBhIHNpZ24gbGFuZ3VhZ2UuDQpUaGVy
ZWZvcmUgSSBpbmNsdWRlZCB0aGlzIHRleHQgaW4gdGhlIGxhdGVzdCBwcm9wb3NhbCBmb3Igc2Vj
dGlvbiA1LjQgYXQgdGhlIGxpbmsgdGhhdCBCZXJuYXJkIHByb3ZpZGVkOg0KDQoiDQoNCkEgc3Bl
Y2lmaWMgc2lnbiBsYW5ndWFnZSBjYW4gYmUgaWRlbnRpZmllZCBieSBpdHMgZXhpc3RlbmNlIGlu
IHRoZSBJQU5BDQoNCnJlZ2lzdHJ5IG9mIGxhbmd1YWdlIHN1YnRhZ3MgYWNjb3JkaW5nIHRvIEJD
UCA0NyBbUkZDNTY0Nl0gLCBhbmQgZmluZGluZw0KDQp0aGF0IHRoZSBsYW5ndWFnZSBzdWJ0YWcg
aXMgZm91bmQgYXQgbGVhc3QgaW4gdHdvIGVudHJpZXMgaW4gdGhlDQoNCnJlZ2lzdHJ5LCBvbmNl
IHdpdGggdGhlIFR5cGUgZmllbGQgImxhbmd1YWdlIiBhbmQgb25jZSB3aXRoIHRoZSBUeXBlDQoN
CmZpZWxkICJleHRsYW5nIiBjb21iaW5lZCB3aXRoIHRoZSBQcmVmaXggZmllbGQgdmFsdWUgInNn
biIuDQoiDQoNClNvIHRoYXQgc2hvdWxkIGJlIHRoZSByZXNwb25zZSBvbiBEYWxlcyByZXF1ZXN0
IHRvIGVhc2lseSBkZWNpZGUgaWYgYSBsYW5ndWFnZSB0YWcgaXMgZm9yIGEgc2lnbiBsYW5ndWFn
ZS4NCg0KV29yc2UgaXMgbmV4dCB0b3BpYyBpbiBpc3N1ZSA0MzogdG8gYXNzZXNzIGlmIGEgbGFu
Z3VhZ2UgdGFnIGlzIGZvciBhIHNwb2tlbiBtb2RhbGl0eSBvciB3cml0dGVuIG1vZGFsaXR5IG9m
IGEgbGFuZ3VhZ2UuDQpNeSB3b3JkaW5nIHByb3Bvc2FsIHN0YXJ0cyB3aXRoIHRoZSBvYnZpb3Vz
IGNhc2VzOiBhIG5vbi1zaWduZWQgbGFuZ3VnZSB0YWcgaW4gYXVkaW8gbWVkaWEgaXMgc3Bva2Vu
LCBhbmQgYSBub24tc2lnbmVkIGxhbmd1YWdlIHRhZyBpbiB0ZXh0IG1lZGlhIGlzIHdyaXR0ZW4u
ICBCdXQgZm9yIG90aGVyIGNhc2VzLCBsaWtlIGluIHZpZGVvIG9yIG1lc3NhZ2Ugb3IgYXBwbGlj
YXRpb24gb3IgbXVsdGlwbGV4ZWQgbWVkaWEsIG90aGVyIGluZGljYXRpb25zIG11c3QgYmUgdXNl
ZCB0byB1bmRlcnN0YW5kIHRoZSBpbnRlbmRlZCBtb2RhbGl0eS4gVGhlIHByb3Bvc2VkIHRleHQg
bWVudGlvbnMgYSBmZXcsIGFuZCBsZWF2ZXMgdG8gYXBwbGljYXRpb25zIHRvIGRlY2lkZSB3aGlj
aCBtZWNoYW5pc21zIHRvIHVzZSBmb3Igc3VjaCBjYXNlcy4gSSB3aXNoIHdlIGZvciB0aGUgYW1i
aWd1b3VzIGNhc2VzIGNvdWxkIHVzZSB0aGUgc2NyaXB0IHN1YnRhZyAtenh4eCB0byBpbmRpY2F0
ZSBzcG9rZW4gbW9kYWxpdHkgYW5kIGEgcmVhbCBzY3JpcHQgc3VidGFnIGV2ZW4gb24gbGFuZ3Vh
Z2Ugc3VidGFncyB3aGVyZSBzY3JpcHQgc3VidGFncyBhcmUgc3VwcHJlc3NlZCwgYmVjYXVzZSB0
aGF0IHdvdWxkIHNhdGlzZnkgaXNzdWUgNDMgbmljZWx5IGFuZCBtYWtlIHNlY3Rpb24gNS40IG11
Y2ggc2hvcnRlciBhbmQgY2xlYXJlci4gQnV0IHdlIGhhdmUgaGFkIHJlc2lzdGFuY2UgYWdhaW5z
dCB0aGF0IHNvbHV0aW9uLg0KDQpUaGUgcHJvcG9zZWQgdGV4dCBtaWdodCBiZSBhIGJpdCBsb25n
IGFuZCBkZXRhaWxlZC4gSSBhbSBwcmVwYXJlZCB0byBhZ3JlZSBvbiBhIHNob3J0ZW5lZCB2ZXJz
aW9uIGlmIHRoZXJlIGFyZSBhbnkgcHJvcG9zYWxzLiBJIHRoaW5rIHRob3VnaCB0aGF0IGNvbnRl
bnRzIG9mIDUuNCBpbiB0aGUgZGlyZWN0aW9uIG9mIG15IHByb3Bvc2FsIGlzIHdoYXQgc2F0aXNm
aWVzICBpc3N1ZSA0MyBhbmQgYWxzbyB0aGUgY29tbWVudHMgbGF0ZWx5IHRoYXQgc2VjdGlvbiA1
LjQgaXMgdG9vIHJlc3RyaWN0aXZlLg0KDQovR3VubmFyDQoNCg0KDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KU0xJTSBtYWlsaW5nIGxpc3QN
Cg0KU0xJTUBpZXRmLm9yZzxtYWlsdG86U0xJTUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQoNCg0KDQotLQ0KDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpHdW5uYXIgSGVsbHN0csO2bQ0KDQpPbW5pdG9y
DQoNCmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBv
bW5pdG9yLnNlPg0KDQorNDYgNzA4IDIwNCAyODgNCg0K

--_000_f75ade4b0f3740c9af26ec274e9857e1EX13D08UWB002antamazonc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2
Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6
MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl
ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0
ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN
Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpo
b2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K
QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY1NTc5NjExNTsNCgltc28tbGlzdC10eXBlOmh5YnJp
ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA0OTExNzI5NCA2NzY5ODcwMyA2NzY5ODcxMyA2
NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5
ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz
dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg
bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu
LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXtt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0
IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K
CXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt
YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkEgZmV3IHBvaW50
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJm
b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g
ZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2lnbiBsYW5n
dWFnZXMgZG8gbm90IG5lY2Vzc2FyaWx5IHVzZSB0aGUgc3VidGFnIOKAmHNnbuKAmS4gSW4gZmFj
dCwgbW9zdCBzaWduIGxhbmd1YWdlcyBoYXZlIHN1YnRhZ3MgdGhhdCBoYXZlIG5vdGhpbmcgdG8g
ZG8gd2l0aA0KIHRoZSDigJhzZ27igJkgc3VidGFnLiBUaGV5IGFyZSBub3Qg4oCYZXh0bGFuZ+KA
mSBhbmQgZG8gbm90IGhhdmUgYSBtYWNyb2xhbmd1YWdlIG9mIOKAmHNnbuKAmS4gRm9yIGV4YW1w
bGUsIGhlcmUgaXMgdGhlIHJlY29yZCBmb3IgQW1lcmljYW4gU2lnbiBMYW5ndWFnZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiUlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPlR5cGU6IGxhbmd1YWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1YnRhZzogYXNlPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRlc2NyaXB0aW9uOiBBbWVyaWNh
biBTaWduIExhbmd1YWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkFkZGVkOiAyMDA5LTA3LTI5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiUlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs
ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6
Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9
IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TaWduIGxhbmd1YWdl
cyBtYXkgaGF2ZSB0aGUgd29yZHMg4oCcU2lnbiBMYW5ndWFnZeKAnSBpbiBvbmUgb2YgdGhlaXIg
RGVzY3JpcHRpb24gZmllbGRzIChub3RpY2UgdGhhdCBJIHNheSDigJxvbmUgb2bigJ0pLiBJ4oCZ
bSBub3Qgc3VyZQ0KIHRoYXQgYWxsIHNpZ24gbGFuZ3VhZ2VzIGhhdmUgdGhpcy4gU29tZW9uZSB3
b3VsZCBoYXZlIHRvIGFzayB0aGUgSVNPIDYzOSBmb2xrcyBpZiB0aGVyZSBhcmUgYW55IG91dGxp
ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz
dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh
c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9
Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z
cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN1cHByZXNzLVNjcmlwdCBpcyBhbiBhZHZpc29yeSBm
aWVsZCBpbiB0aGUgcmVnaXN0cnkuIEl0IGRvZXMgbm90IGNhdXNlIG9yIHJlcXVpcmUgdGhhdCB0
aGUgc2NyaXB0IHN1YnRhZyBiZSBvbWl0dGVkLiBJdCBpcyBhbHNvDQogYW4gaW5jb21wbGV0ZSBi
aXQgb2YgZG9jdW1lbnRhdGlvbjogbWFueSBsYW5ndWFnZXMgdGhhdCBmaXQgdGhlIGNyaXRlcmlh
IGZvciBTdXBwcmVzcy1TY3JpcHQgZG8gbm90IGhhdmUgdGhlIGZpZWxkIGluIHRoZSByZWdpc3Ry
eS4gVXNlIG9yIG5vbi11c2Ugb2YgdGhlIHNjcmlwdCBzdWJ0YWcgaXMgbm90IGEgdmVyeSByZWxp
YWJsZSBpbmRpY2F0b3Igb2YgbGFuZ3VhZ2UgbW9kYWxpdHkgb24gaXRzIG93bi4gVGFncyBsaWtl
IOKAnGVuLVVT4oCdIG9yIOKAnGRl4oCdDQogZnVuY3Rpb24gd2VsbCBmb3IgaWRlbnRpZnlpbmcg
dGhlIGxhbmd1YWdlIG9mIHZhcmlvdXMgbWF0ZXJpYWxzIGFuZCBJIGNhdXRpb24gZm9sa3MgdGhh
dCwgaW4gbXkgZXhwZXJpZW5jZSwgYXJjYW5lIHJ1bGVzIGFib3V0IHRoZSBzcGVjaWFsaXplZCB1
c2Ugb2Ygc3VidGFncyBhcmUgbGlrZWx5IHRvIGJlIGlnbm9yZWQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PdmVyYWxsLCBteSBzdWdnZXN0aW9uIHdvdWxkIGJl
OiBpZiB5b3UgbmVlZCB0byBkZWFsIHdpdGggbW9kYWxpdHksIGRvbuKAmXQgdXNlIChleGlzdGlu
ZykgbGFuZ3VhZ2Ugc3VidGFncyBmb3IgaXQuIEVuY29kZSBtZXRhZGF0YSB0byBtYWtlIHRoaW5n
cyBleHBsaWNpdC4gVXNlDQogcHJpdmF0ZSB1c2Ugc3VidGFncyBvciBhbiBleHRlbnNpb24gZm9y
IGl0IGlmIHlvdSBtdXN0LiBCdXQgZG9u4oCZdCBwcm92aWRlIHN1cGVyLXNwZWNpYWwgbWVhbmlu
ZyBmb3Igc3VidGFncy4gUGVyc29uYWxseSwgSSB0ZW5kIHRvIHRoaW5rIHlvdSBzaG91bGQgZW5j
b2RlIG1vZGFsaXR5IG9uIGEgZGlmZmVyZW50IGxldmVsLiBTb21lb25lIHdobyBpcyBoYXJkIG9m
IGhlYXJpbmcgYW5kIGxvdyB2aXNpb24gaGFzIGRpZmZlcmVudCBuZWVkcyBmcm9tDQogYSBibGlu
ZCB1c2VyIHdobyBoYXMgZGlmZmVyZW50IG5lZWRzIGZyb20gYSBkZWFmIHBlcnNvbiB3aXRoIGxp
bWl0ZWQgbW9iaWxpdHnigKYgZXRjLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5BZGRpc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xpZCBibHVl
IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFNMSU0gW21haWx0bzpzbGltLWJvdW5jZXNA
aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50
OjwvYj4gU2F0dXJkYXksIE5vdmVtYmVyIDE4LCAyMDE3IDk6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+
IEd1bm5hciBIZWxsc3Ryw7ZtICZsdDtndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UmZ3Q7PGJy
Pg0KPGI+Q2M6PC9iPiBzbGltQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU2xp
bV0gTW92aW5nIGZvcndhcmQgb24gZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxh
bmd1YWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkd1bm5hciBzYWlkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+JnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+SSBlYXJsaWVy
IHRob3VnaHQgdGhhdCBhbiBhcHBsaWNhdGlvbiBuZWVkZWQgdG8gbG9vayBpbnRvIHRoZSBsYW5n
dWFnZSBzdWJ0YWcgRGVzY3JpcHRpb24gdG8gZmluZCB0aGUgd29yZCAmcXVvdDtzaWduJnF1b3Q7
IHRoZXJlIGluIHRoZSB0ZXh0IHN0cmluZy4gVGhhdCBpcyBub3QgYSBnb29kIHNvbHV0aW9uLjwv
c3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+W0JBXSBBZ3JlZWQuIEFsc28sIGFzIGluZGljYXRlZCBpbiBSRkMgNTY0NiBTZWN0
aW9uIDQuMS4yIGFuZCB0aGUgSUFOQSByZWdpc3RyeSAoPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFu
YS5vcmcvYXNzaWdubWVudHMvbGFuZ3VhZ2Utc3VidGFnLXJlZ2lzdHJ5L2xhbmd1YWdlLXN1YnRh
Zy1yZWdpc3RyeSI+aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbGFuZ3VhZ2Utc3Vi
dGFnLXJlZ2lzdHJ5L2xhbmd1YWdlLXN1YnRhZy1yZWdpc3RyeTwvYT4pLA0KIHNpZ24gbGFuZ3Vh
Z2VzIG1heSBub3QgaGF2ZSBhbHdheXMgaGF2ZSBhIHN1YnRhZyBvZiAnc2duJzombmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyBTaWduIGxhbmd1YWdlcyBzaGFyZSBhIG1vZGUgb2YgY29tbXVuaWNh
dGlvbiByYXRoZXIgdGhhbiBhIGxpbmd1aXN0aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaGVyaXRhZ2UuJm5ic3A7
IFRoZXJlIGFyZSBtYW55IHNpZ24gbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBkZXZlbG9wZWQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsgaW5kZXBlbmRlbnRseSwgYW5kIHRoZSBzdWJ0YWcgJ3NnbicgaW5kaWNhdGVzIG9ubHkg
dGhlIHByZXNlbmNlIG9mIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2lnbiBsYW5ndWFnZS4mbmJzcDsgQSBudW1i
ZXIgb2Ygc2lnbiBsYW5ndWFnZXMgYWxzbyBoYWQgZ3JhbmRmYXRoZXJlZDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0
YWdzIHJlZ2lzdGVyZWQgZm9yIHRoZW0gZHVyaW5nIHRoZSA8YSBocmVmPSJodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjMzA2NiI+UkZDIDMwNjY8L2E+IGVyYS4mbmJzcDsgRm9yIGV4YW1w
bGUsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyBncmFuZGZhdGhlcmVkIHRhZyAmcXVvdDtzZ24tVVMmcXVvdDsg
d2FzIHJlZ2lzdGVyZWQgdG8gcmVwcmVzZW50ICdBbWVyaWNhbiBTaWduPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IExh
bmd1YWdlJyBzcGVjaWZpY2FsbHksIHdpdGhvdXQgcmVmZXJlbmNlIHRvIHRoZSBVbml0ZWQgU3Rh
dGVzLiZuYnNwOyBUaGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzIHN0aWxsIHZhbGlkLCBidXQgZGVwcmVjYXRl
ZDogYSBkb2N1bWVudCBpbiBBbWVyaWNhbiBTaWduIExhbmd1YWdlPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNhbiBi
ZSBsYWJlbGVkIGVpdGhlciAmcXVvdDthc2UmcXVvdDsgb3IgJnF1b3Q7c2duLWFzZSZxdW90OyAo
dGhlICdhc2UnIHN1YnRhZyBpcyBmb3IgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGxhbmd1YWdlIGNhbGxlZCAn
QW1lcmljYW4gU2lnbiBMYW5ndWFnZScpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HdW5uYXIgYWxzbyBzYWlkOiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjcuNXB0O3doaXRlLXNwYWNlOnByZS13cmFwO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdy
YXA6bm9ybWFsO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj4mcXVvdDtBIHNwZWNpZmljIHNpZ24g
bGFuZ3VhZ2UgY2FuIGJlIGlkZW50aWZpZWQgYnkgaXRzIGV4aXN0ZW5jZSBpbiB0aGUgSUFOQSA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41cHQi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5yZWdpc3Ry
eSBvZiBsYW5ndWFnZSBzdWJ0YWdzIGFjY29yZGluZyB0byBCQ1AgNDcgW1JGQzU2NDZdICwgYW5k
IGZpbmRpbmcgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMz
MyI+dGhhdCB0aGUgbGFuZ3VhZ2Ugc3VidGFnIGlzIGZvdW5kIGF0IGxlYXN0IGluIHR3byBlbnRy
aWVzIGluIHRoZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i
b3R0b206Ny41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMz
MzMzIj5yZWdpc3RyeSwgb25jZSB3aXRoIHRoZSBUeXBlIGZpZWxkICZxdW90O2xhbmd1YWdlJnF1
b3Q7IGFuZCBvbmNlIHdpdGggdGhlIFR5cGUgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u
c29sYXM7Y29sb3I6IzMzMzMzMyI+ZmllbGQgJnF1b3Q7ZXh0bGFuZyZxdW90OyBjb21iaW5lZCB3
aXRoIHRoZSBQcmVmaXggZmllbGQgdmFsdWUgJnF1b3Q7c2duJnF1b3Q7LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjVwdCI+U28gdGhhdCBzaG91bGQgYmUgdGhlIHJlc3BvbnNlIG9uIERhbGVzIHJl
cXVlc3QgdG8gZWFzaWx5IGRlY2lkZSBpZiBhIGxhbmd1YWdlIHRhZyBpcyBmb3IgYSBzaWduIGxh
bmd1YWdlLiZuYnNwOzwvc3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JBXSZuYnNwOyBMb29raW5nIGF0IHRoZSBJQU5BIHJl
Z2lzdHJ5LCBoYXZpbmcgYSBUeXBlIGZpZWxkICZxdW90O2V4dGxhbmcmcXVvdDsgY29tYmluZWQg
d2l0aCB0aGUgUHJlZml4IGZpZWxkIHZhbHVlICdzZ24nIHNlZW1zIHRvIGJlIHVzZWQgYXMgYW4g
aW5kaWNhdG9yIG9mIGEgc2lnbiBsYW5ndWFnZS4mbmJzcDsgRG8geW91IHRoaW5rIHdlIGNhbiBy
ZWx5IG9uIHRoaXM/IEN1cnJlbnRseSB0aGlzIGlzIG9ubHkgYSBTSE9VTEQmbmJzcDsgaW4gUkZD
DQogNTY0NiBTZWN0aW9uIDMuNDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4mbmJz
cDsgU2lnbiBsYW5ndWFnZXMgU0hPVUxEIGhhdmUgYW4gJ2V4dGxhbmcnIHJlY29yZCB3aXRoIGFu
J1ByZWZpeCcgb2YgJ3NnbicuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj4mcXVvdDtNeSB3b3JkaW5nIHByb3Bvc2Fs
IHN0YXJ0cyB3aXRoIHRoZSBvYnZpb3VzIGNhc2VzOiBhIG5vbi1zaWduZWQgbGFuZ3VhZ2UgdGFn
IGluIGF1ZGlvIG1lZGlhIGlzIHNwb2tlbiwgYW5kIGEgbm9uLXNpZ25lZCBsYW5ndWFnZSB0YWcg
aW4gdGV4dCBtZWRpYSBpcyB3cml0dGVuLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPltCQV0gQXNzdW1pbmcgeW91ciBzdWdnZXN0ZWQgYXBwcm9hY2ggYWxsb3dz
IHVzIHRvIHJlbGlhYmx5IGRldGVybWluZSBub24tc2lnbiBsYW5ndWFnZXMsIHRoaXMgc2VlbXMg
c29saWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPkd1bm5hciBmdXJ0aGVyIHNhaWQ6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O0J1dCBmb3Igb3Ro
ZXIgY2FzZXMsIGxpa2UgaW4gdmlkZW8gb3IgbWVzc2FnZSBvciBhcHBsaWNhdGlvbiBvciBtdWx0
aXBsZXhlZCBtZWRpYSwgb3RoZXIgaW5kaWNhdGlvbnMgbXVzdCBiZSB1c2VkIHRvIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnVuZGVyc3Rh
bmQgdGhlIGludGVuZGVkIG1vZGFsaXR5Li4uIEkgd2lzaCBmb3IgdGhlIGFtYmlndW91cyBjYXNl
cyB3ZSBjb3VsZCB1c2UgdGhlIHNjcmlwdCBzdWJ0YWcgLXp4eHggdG8gaW5kaWNhdGU8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zcG9rZW4g
bW9kYWxpdHkgYW5kIGEgcmVhbCBzY3JpcHQgc3VidGFnLi4uJnF1b3Q7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0JBXSBUaGlz
IGlzIHdoZXJlIEkgYmVjb21lIHVuZWFzeSwgYmVjYXVzZSB3aXRob3V0IGFuIGV4cGxpY2l0IG1l
Y2hhbmlzbSBzdWNoIGFzIHNjcmlwdCBzdWJ0YWdzLCB0aGVyZSBpcyB0aGUgcG90ZW50aWFsIGZv
ciBhbWJpZ3VpdHkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+VHJ5aW5nIHRvIGFkZHJlc3MgcmVkdWNlIHRoYXQgYW1iaWd1aXR5IHZpYSBo
ZXVyaXN0aWNzIGNvdWxkIHR1cm4gb3V0IHRvIGJlIGEgYmFkIGlkZWEsIGNvbXBhcmVkIHdpdGgg
cHJvY2VlZGluZyBtb3JlIGNhdXRpb3VzbHkgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+YnkgbGVhdmluZyBiZWhhdmlvciB1bmRlZmluZWQg
Zm9yIG5vdyBhbmQgcmV2aXNpdGluZyB0aGUgc2l0dWF0aW9uIGxhdGVyIHdoZW4gd2UgdW5kZXJz
dGFuZCB0aGUgcHJvYmxlbSBiZXR0ZXIuIEZvciBleGFtcGxlOiA8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7Ym94LXNpemluZzpi
b3JkZXItYm94O3dvcmQtd3JhcDpub3JtYWw7Ym9yZGVyLXJhZGl1czo0cHg7d2hpdGUtc3BhY2U6
cHJlLXdyYXA7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz
O2NvbG9yOiMzMzMzMzMiPiZxdW90O1VzZSBmb3Igc2VuZGluZyBvZiBhIHZpc3VhbCB2aWV3IG9m
IGEgc3BlYWtpbmcgcGVyc29uIG1heSBiZSBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlICZxdW90O3Nw
ZWFrZXImcXVvdDsgaW4gYW4gU0RQIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz
O2NvbG9yOiMzMzMzMzMiPkNvbnRlbnQgYXR0cmlidXRlIGFjY29yZGluZyB0byBSRkMgNDc5NiBb
UkZDNDc5Nl0gaW4gYSAmcXVvdDt2aWRlbyZxdW90OyBtZWRpYSBzdHJlYW0gb3IgYW5vdGhlciBt
ZWRpYSBjYXJyeWluZyB2aWRlbyAoZS5nLiAmcXVvdDttZXNzYWdlJnF1b3Q7IG9yICZxdW90O2Fw
cGxpY2F0aW9uJnF1b3Q7KS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1ib3R0b206Ny41cHQ7Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpu
b3JtYWw7Ym9yZGVyLXJhZGl1czo0cHg7d2hpdGUtc3BhY2U6cHJlLXdyYXA7b3ZlcmZsb3c6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMiPltCQV0g
VGhlcmUgYXJlIHF1aXRlIGEgZmV3IHBvdGVudGlhbCBjb3JuZXIgY2FzZXMgaGVyZS4gRm9yIGV4
YW1wbGUsIGlmICZxdW90O2VuLVVTJnF1b3Q7IGxhbmd1YWdlIGlzIGluY2x1ZGVkIGluIGFuIG9m
ZmVyIHdpdGhpbiBhIHZpZGVvIG0tbGluZSwgc2hvdWxkIHRoZSBhbnN3ZXJlciBhc3N1bWUgdGhp
cyBpbXBsaWVzIGEgd2lsbGluZ25lc3MgdG8gbGlwIHJlYWQgVVMgRW5nbGlzaCBpZiB0aGUgdmFs
dWUgJnF1b3Q7c3BlYWtlciZxdW90OyBpcyBpbiB0aGUgQ29udGVudCBhdHRyaWJ1dGU/Jm5ic3A7
IFdoYXQgY2FuIGJlIGFzc3VtZWQgaWYgYSB2YWx1ZSBvdGhlciB0aGFuICZxdW90O3NwZWFrZXIm
cXVvdDsgaXMgaW4gdGhlIENvbnRlbnQgYXR0cmlidXRlPyBNaWdodCB0aGF0IHJlcHJlc2VudCBz
b21ldGhpbmcgZW50aXJlbHkgZGlmZmVyZW50LCBzdWNoIGFzIHRoZSBkZXNpcmUgdG8gcmVjZWl2
ZSBjYXB0aW9uaW5nIGluIFVTIEVuZ2xpc2g/IElmIHNvLCBob3cgY291bGQgdGhlIE9mZmVyZXIg
aW5kaWNhdGUgYm90aCB0aGUgY2FwYWJpbGl0eSBvZiBsaXByZWFkaW5nIGFuZCB0aGUgYWJpbGl0
eSB0byBoYW5kbGUgY2FwdGlvbnM/IEFuZCB3aGF0IGhhcHBlbnMgaWYgdGhlIEFuc3dlcmVyIGRv
ZXNuJ3QgbWltaWMgdGhlIENvbnRlbnQgYXR0cmlidXRlIGluIHRoZSBPZmZlcj8gU2VlbXMgbGlr
ZSB0aGVyZSBhcmUgc29tZSBwb3RlbnRpYWwgJnF1b3Q7Z290Y2hhcyZxdW90OyBoZXJlLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O3dv
cmQtd3JhcDpub3JtYWw7Ym9yZGVyLXJhZGl1czo0cHg7d2hpdGUtc3BhY2U6cHJlLXdyYXA7b3Zl
cmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtVc2Ugb2Ygd3JpdHRl
biBtb2RhbGl0eSBpbiBhbm90aGVyIG1lZGlhIHN0cmVhbSB0aGFuIDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtib3gtc2l6aW5nOmJvcmRl
ci1ib3g7d29yZC13cmFwOm5vcm1hbDtib3JkZXItcmFkaXVzOjRweDt3aGl0ZS1zcGFjZTpwcmUt
d3JhcDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s
b3I6IzMzMzMzMyI+JnF1b3Q7dGV4dCZxdW90OywgbWF5IGJlIGRpc2NyaW1pbmF0ZWQgYnkgdXNl
IG9mIGEgc2NyaXB0IHN1YnRhZyBpbiB0aGUgbGFuZ3VhZ2UgPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+dGFnLCB3aGVyZSB0aGF0IGlzIGFwcHJvcHJp
YXRlLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv
dHRvbTo3LjVwdDtib3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOm5vcm1hbDtib3JkZXIt
cmFkaXVzOjRweDt3aGl0ZS1zcGFjZTpwcmUtd3JhcDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+W0JBXSBXaGF0IGlmIHRoZSBs
YW5ndWFnZSBpbiBxdWVzdGlvbiBoYXMgc2NyaXB0IHN1YnRhZ3Mgc3VwcHJlc3NlZD8gV2hhdCBp
ZiB0aGUgT2ZmZXJlciBpbmNsdWRlcyBhIHNjcmlwdCBzdWJ0YWcgaW4gdGhlIHZpZGVvIG0tbGlu
ZSBidXQgYWxzbyAmcXVvdDtzcGVha2VyJnF1b3Q7IGluIHRoZSBDb250ZW50IGF0dHJpYnV0ZT8g
QWdhaW4sIHRoZXJlIGNvdWxkIGJlIHF1aXRlIGEgZmV3IGNvcm5lciBjYXNlcyBsdXJraW5nIGhl
cmUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBOb3YgMTgsIDIwMTcgYXQgMjozMyBQTSwgR3VubmFy
IEhlbGxzdHLDtm0gJmx0OzxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iu
c2UiIHRhcmdldD0iX2JsYW5rIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoYW5rcyBCZXJuYXJkIGZvciBwdXNoaW5nIGZvciBjbG9zaW5nIHRoZSBsYXN0IG9w
ZW4gaXNzdWUuIDxvOnA+DQo8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkRlbiAyMDE3LTExLTE4IGtsLiAxOTo0Niwgc2tyZXYgQmVybmFyZCBBYm9iYTo8YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0
IHRoaXMgcG9pbnQsIG9ubHkgYSBzaW5nbGUgSXNzdWUgKDQzKSByZW1haW5zIG9wZW4gb24gZHJh
ZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlOjombmJzcDsNCjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdHJh
Yy5pZXRmLm9yZy90cmFjL3NsaW0vdGlja2V0LzQzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90
cmFjLmlldGYub3JnL3RyYWMvc2xpbS90aWNrZXQvNDM8L2E+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgcmVsYXRlcyB0byB0aGUgbW9k
YWxpdHkgb2YgYSBsYW5ndWFnZSBpbmRpY2F0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DdXJyZW50bHksIEd1bm5hciBoYXMg
c3VnZ2VzdGVkIGEgbW9kaWZpY2F0aW9uIHRvIHRoZSB0ZXh0IG9mIFNlY3Rpb24gNS40IGluIG9y
ZGVyIHRvIGFkZHJlc3MgdGhlIGlzc3VlOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p
ZXRmLm9yZy9hcmNoL21zZy9zbGltL0E0YjZXcGdoMFowenBYS3Fwd0Y5YmZkVzM1ZyIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2xpbS9BNGI2
V3BnaDBaMHpwWEtxcHdGOWJmZFczNWc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIFdHIHBhcnRpY2lwYW50cyByZXZpZXcgdGhp
cyBzdWdnZXN0ZWQgY2hhbmdlLCBzbyB0aGF0IHdlIGNhbiBkZXRlcm1pbmUgaG93IHRvIG1vdmUg
Zm9yd2FyZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Q3VycmVudGx5LCBTZWN0aW9uIDUuNCBzdGF0ZXMgdGhhdDombmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFr
LXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7IFRoZSBwcm9ibGVtIG9mIGtub3dpbmcgd2hpY2ggbGFuZ3VhZ2UgdGFncyBhcmUg
c2lnbmVkIGFuZCB3aGljaCBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbm90IGlzIG91dCBvZiBzY29wZSBvZiB0
aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGVhcmxp
ZXIgdGhvdWdodCB0aGF0IGFuIGFwcGxpY2F0aW9uIG5lZWRlZCB0byBsb29rIGludG8gdGhlIGxh
bmd1YWdlIHN1YnRhZyBEZXNjcmlwdGlvbiB0byBmaW5kIHRoZSB3b3JkICZxdW90O3NpZ24mcXVv
dDsgdGhlcmUgaW4gdGhlIHRleHQgc3RyaW5nLiBUaGF0IGlzIG5vdCBhIGdvb2Qgc29sdXRpb24u
IEJ1dCB3aGVuIHN0dWR5aW5nIHRoZSB0b3BpYyBhZ2FpbiBpbiBSRkMgNTY0NiBJIGZvdW5kIHRo
YXQgdGhlcmUgaXMNCiBhIGNvbnNpc3RlbnQgbWFjaGluZS1pbXBsZW1lbnRhYmxlIHdheSB0byBh
c3Nlc3MgaWYgYSBsYW5ndWFnZSBzdWJ0YWcgaXMgZm9yIGEgc2lnbiBsYW5ndWFnZS4NCjxicj4N
ClRoZXJlZm9yZSBJIGluY2x1ZGVkIHRoaXMgdGV4dCBpbiB0aGUgbGF0ZXN0IHByb3Bvc2FsIGZv
ciBzZWN0aW9uIDUuNCBhdCB0aGUgbGluayB0aGF0IEJlcm5hcmQgcHJvdmlkZWQ6PGJyPg0KPGJy
Pg0KJnF1b3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVw
dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s
b3I6IzMzMzMzMyI+QSBzcGVjaWZpYyBzaWduIGxhbmd1YWdlIGNhbiBiZSBpZGVudGlmaWVkIGJ5
IGl0cyBleGlzdGVuY2UgaW4gdGhlIElBTkEgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzIj5yZWdpc3RyeSBvZiBsYW5ndWFn
ZSBzdWJ0YWdzIGFjY29yZGluZyB0byBCQ1AgNDcgW1JGQzU2NDZdICwgYW5kIGZpbmRpbmcgPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0O2Jh
Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj
MzMzMzMzIj50aGF0IHRoZSBsYW5ndWFnZSBzdWJ0YWcgaXMgZm91bmQgYXQgbGVhc3QgaW4gdHdv
IGVudHJpZXMgaW4gdGhlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWJvdHRvbTo3LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+cmVnaXN0cnksIG9uY2Ugd2l0aCB0aGUgVHlwZSBm
aWVsZCAmcXVvdDtsYW5ndWFnZSZxdW90OyBhbmQgb25jZSB3aXRoIHRoZSBUeXBlIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdDtiYWNrZ3Jv
dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMz
MyI+ZmllbGQgJnF1b3Q7ZXh0bGFuZyZxdW90OyBjb21iaW5lZCB3aXRoIHRoZSBQcmVmaXggZmll
bGQgdmFsdWUgJnF1b3Q7c2duJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+JnF1b3Q7PGJyPg0KPGJyPg0KU28gdGhhdCBzaG91bGQgYmUgdGhlIHJl
c3BvbnNlIG9uIERhbGVzIHJlcXVlc3QgdG8gZWFzaWx5IGRlY2lkZSBpZiBhIGxhbmd1YWdlIHRh
ZyBpcyBmb3IgYSBzaWduIGxhbmd1YWdlLg0KPGJyPg0KPGJyPg0KV29yc2UgaXMgbmV4dCB0b3Bp
YyBpbiBpc3N1ZSA0MzogdG8gYXNzZXNzIGlmIGEgbGFuZ3VhZ2UgdGFnIGlzIGZvciBhIHNwb2tl
biBtb2RhbGl0eSBvciB3cml0dGVuIG1vZGFsaXR5IG9mIGEgbGFuZ3VhZ2UuPGJyPg0KTXkgd29y
ZGluZyBwcm9wb3NhbCBzdGFydHMgd2l0aCB0aGUgb2J2aW91cyBjYXNlczogYSBub24tc2lnbmVk
IGxhbmd1Z2UgdGFnIGluIGF1ZGlvIG1lZGlhIGlzIHNwb2tlbiwgYW5kIGEgbm9uLXNpZ25lZCBs
YW5ndWFnZSB0YWcgaW4gdGV4dCBtZWRpYSBpcyB3cml0dGVuLiZuYnNwOyBCdXQgZm9yIG90aGVy
IGNhc2VzLCBsaWtlIGluIHZpZGVvIG9yIG1lc3NhZ2Ugb3IgYXBwbGljYXRpb24gb3IgbXVsdGlw
bGV4ZWQgbWVkaWEsIG90aGVyIGluZGljYXRpb25zDQogbXVzdCBiZSB1c2VkIHRvIHVuZGVyc3Rh
bmQgdGhlIGludGVuZGVkIG1vZGFsaXR5LiBUaGUgcHJvcG9zZWQgdGV4dCBtZW50aW9ucyBhIGZl
dywgYW5kIGxlYXZlcyB0byBhcHBsaWNhdGlvbnMgdG8gZGVjaWRlIHdoaWNoIG1lY2hhbmlzbXMg
dG8gdXNlIGZvciBzdWNoIGNhc2VzLiBJIHdpc2ggd2UgZm9yIHRoZSBhbWJpZ3VvdXMgY2FzZXMg
Y291bGQgdXNlIHRoZSBzY3JpcHQgc3VidGFnIC16eHh4IHRvIGluZGljYXRlIHNwb2tlbiBtb2Rh
bGl0eQ0KIGFuZCBhIHJlYWwgc2NyaXB0IHN1YnRhZyBldmVuIG9uIGxhbmd1YWdlIHN1YnRhZ3Mg
d2hlcmUgc2NyaXB0IHN1YnRhZ3MgYXJlIHN1cHByZXNzZWQsIGJlY2F1c2UgdGhhdCB3b3VsZCBz
YXRpc2Z5IGlzc3VlIDQzIG5pY2VseSBhbmQgbWFrZSBzZWN0aW9uIDUuNCBtdWNoIHNob3J0ZXIg
YW5kIGNsZWFyZXIuIEJ1dCB3ZSBoYXZlIGhhZCByZXNpc3RhbmNlIGFnYWluc3QgdGhhdCBzb2x1
dGlvbi4NCjxicj4NCjxicj4NClRoZSBwcm9wb3NlZCB0ZXh0IG1pZ2h0IGJlIGEgYml0IGxvbmcg
YW5kIGRldGFpbGVkLiBJIGFtIHByZXBhcmVkIHRvIGFncmVlIG9uIGEgc2hvcnRlbmVkIHZlcnNp
b24gaWYgdGhlcmUgYXJlIGFueSBwcm9wb3NhbHMuIEkgdGhpbmsgdGhvdWdoIHRoYXQgY29udGVu
dHMgb2YgNS40IGluIHRoZSBkaXJlY3Rpb24gb2YgbXkgcHJvcG9zYWwgaXMgd2hhdCBzYXRpc2Zp
ZXMmbmJzcDsgaXNzdWUgNDMgYW5kIGFsc28gdGhlIGNvbW1lbnRzIGxhdGVseSB0aGF0IHNlY3Rp
b24NCiA1LjQgaXMgdG9vIHJlc3RyaWN0aXZlLiA8YnI+DQo8YnI+DQovR3VubmFyPGJyPg0KJm5i
c3A7PGJyPg0KPGJyPg0KJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlNMSU0gbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxw
cmU+PGEgaHJlZj0ibWFpbHRvOlNMSU1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5TTElNQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTwvYT48c3BhbiBjbGFzcz0iaG9lbnpiIj48
c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5HdW5uYXIgSGVsbHN0csO2
bTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4
OCI+T21uaXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6Izg4ODg4OCI+PGEgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIg
dGFyZ2V0PSJfYmxhbmsiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiYjNDM7NDYg
NzA4IDIwNCAyODg8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_f75ade4b0f3740c9af26ec274e9857e1EX13D08UWB002antamazonc_--


From nobody Sun Nov 19 15:53: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 B7C021201FA for ; Sun, 19 Nov 2017 15:52:59 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lIDAtKN-Iuo8 for ; Sun, 19 Nov 2017 15:52:50 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B9FEC124BE8 for ; Sun, 19 Nov 2017 15:52:50 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 19 Nov 2017 15:52:55 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
X-Mailer: Eudora for Mac OS X
Date: Sun, 19 Nov 2017 15:52:47 -0800
To: Bernard Aboba , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Sun, 19 Nov 2017 23:53:00 -0000

My view of issue #43 remains that we do not need to specify a 
mechanism for determining which tags are signed.  In the email 
discussion of the past month or so, I fear we are drifting into 
adding complexity rather than removing it.  I think the way forward 
is to keep this document as simple as possible.  As Bernard notes in 
his email of 10/23, there is no benefit in this case of explicitly 
saying that certain things are not defined.  Since the document does 
not define them, they are undefined in the document.

At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>  In other words,it is not clear to me how Section 5.4's discussion 
> of scope improves or clarifies the situation in any way - and there 
> is some possibility that it could cause problems.


I believe comment #43 should be closed as no longer applicable, since 
the text against which it was generated has been deleted.  (I've said 
this before, and I believe it remains the case.)

The comment from which #43 derives was made against a version of the 
document that had text explicitly discussing signed versus unsigned 
tags.  That text was subsequently deleted.

Here is the comment from which #43 derived:

>     5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>     Note that while signed language tags are used with a video stream
>  to
>     indicate sign language, a spoken language tag for a video stream
>  in
>     parallel with an audio stream with the same spoken language tag
>     indicates a request for a supplemental video stream to see the
>     speaker.
>
>  And there's a similar paragraph in 5.4:
>
>>     A spoken language tag for a video stream in conjunction with an
>  audio
>>     stream with the same language might indicate a request for
>>     supplemental video to see the speaker.
>
>  I think this mechanism needs to be described more exactly, and in
>  particular, it should not depend on the UA understanding which
>  language tags are spoken language tags.  It seems to me that a
>  workable rule is that there is an audio stream and a video stream and
>  they specify exactly the same language tag in their respective
>  humintlang attributes.  In that case, it is a request for a spoken
>  language with simultaneous video of the speaker, and those requests
>  should be considered satisfied only if both streams can be
>  established.

The offending text that was in 5.2 and 5.4 was deleted.

The only remaining text that even mentions the issue is Section 5.4:

    The behavior when specifying a non-signed language tag for a video
    media stream, or a signed language tag for an audio or text media
    stream, is not defined in this document.

    The problem of knowing which language tags are signed and which are
    not is out of scope of this document.

So, let's delete Section 5.4 and be done with it.  Neither of the 
statements is necessary.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Make it right before you make it faster.


From nobody Sun Nov 19 19:47: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 B6001126D45 for ; Sun, 19 Nov 2017 19:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 1FLETZTR5jGG for ; Sun, 19 Nov 2017 19:47:47 -0800 (PST)
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 8A894124E15 for ; Sun, 19 Nov 2017 19:47:47 -0800 (PST)
Received: by mail-vk0-x22e.google.com with SMTP id o70so4782270vkc.9 for ; Sun, 19 Nov 2017 19:47:47 -0800 (PST)
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=ApS77iY+ZTe4IOVv3bGo6eibWExU1rveH1sWxdbTEFI=; b=uS//r296+uBXI2vMjFsCZ7zD1pTUIx9BS+GfF6LamuybBxZUTX263bOmu2Ju1a2l7l Kej1+RioLSo625+wQ26dlQEBD/hCHpah0irUvpCMInIYyRJLijkLQtiy4vj0ffJkPBjM N6sE38gZvsCNtU6tPi07z2XXTGWI8kEQI3tm6Jr69MNla+DW0gBf94kkNsmLuNGk+SAz gqo9YrI0b25rmw3HP77QXZmBEsK6676t40vRgPsG3V3vm2v7rQmGRmW5TbDNzdiBZVEw 9YTjlYySLlXSAF/NKCHWCI4/bxB8uwkwdIvTtriY7EsXAB7Hf8HeW6ZQViHq26jUwqNm I/SQ==
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=ApS77iY+ZTe4IOVv3bGo6eibWExU1rveH1sWxdbTEFI=; b=bbwLOu7p6bFjWpFBmdLxtVGKGoaSIn+X9Wotjty7cmEJ6ghtrm5I6wcKvfk9un+YYZ fG6syVYKRxPVJ4PrB4SHBOcl9rX7/MnmUelSkCaUCk55Fr6ir3O9n7CcZT0cgb5Dph5V SMfCqAfx5fVi1Te2VZgVBLpw/3nE8477mAb30uFCItzCE42bZXm5h4FPIEiVHvL366Cx NNoSy9euls5TRDtk3nVNDUGx3yZiSWTbCe/J33MtYKujhSEYP+mcRklrwgacWPYtw8CD 2BT4r5MXTY/D4DEGUNa/Wl1Aawt/5qufEG70muX3THvChVxwoouVvrJJNmvAzW9o+zrq WMRw==
X-Gm-Message-State: AJaThX5unbvQnNtS+7kGui5tjSAMxymUZWiYcUbQtuJkdesy8zW2RtBR TBsRtFXB7Ao5DyXGbX2iXpnDfVcJ300pGcmHGRcBq22E
X-Google-Smtp-Source: AGs4zMaxBRf+t7S6b9s3o6uZ9wb0fcwSnQkaOeCe8keeVQU5PrJCpJIRsWN/85qW4PfAuSxITYlLxZDmGfnC4GG3ayQ=
X-Received: by 10.31.5.66 with SMTP id 63mr9586637vkf.15.1511149666314; Sun, 19 Nov 2017 19:47:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Sun, 19 Nov 2017 19:47:25 -0800 (PST)
In-Reply-To: 
References:  
From: Bernard Aboba 
Date: Sun, 19 Nov 2017 19:47:25 -0800
Message-ID: 
To: Randall Gellens 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a1143dd5a102e6d055e61f35d"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 03:47:50 -0000

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

"So let's delete Section 5.4 and be done with it.  Neither of the
statements is necessary."

[BA]  I agree that Section 5.4 does not add much value as it stands.

"Non-signed" is not used outside of Section 5.4, so there would not appear
to be a need to define it if Section 5.4 were to be deleted.

However, the term "signed" is used in 7 other places in the document other
than in Section 5.4.

So we may need to find a reference to define that term.

If Gunnar's suggested definition can be confirmed,  this might be as simple
as adding a reference to the IANA language tag repository.

On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens 
wrote:

> My view of issue #43 remains that we do not need to specify a mechanism
> for determining which tags are signed.  In the email discussion of the past
> month or so, I fear we are drifting into adding complexity rather than
> removing it.  I think the way forward is to keep this document as simple as
> possible.  As Bernard notes in his email of 10/23, there is no benefit in
> this case of explicitly saying that certain things are not defined.  Since
> the document does not define them, they are undefined in the document.
>
> At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>
>>  In other words,it is not clear to me how Section 5.4's discussion of
>> scope improves or clarifies the situation in any way - and there is some
>> possibility that it could cause problems.
>>
>
>
> I believe comment #43 should be closed as no longer applicable, since the
> text against which it was generated has been deleted.  (I've said this
> before, and I believe it remains the case.)
>
> The comment from which #43 derives was made against a version of the
> document that had text explicitly discussing signed versus unsigned tags.
> That text was subsequently deleted.
>
> Here is the comment from which #43 derived:
>
>     5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>     Note that while signed language tags are used with a video stream
>>  to
>>     indicate sign language, a spoken language tag for a video stream
>>  in
>>     parallel with an audio stream with the same spoken language tag
>>     indicates a request for a supplemental video stream to see the
>>     speaker.
>>
>>  And there's a similar paragraph in 5.4:
>>
>>     A spoken language tag for a video stream in conjunction with an
>>>
>>  audio
>>
>>>     stream with the same language might indicate a request for
>>>     supplemental video to see the speaker.
>>>
>>
>>  I think this mechanism needs to be described more exactly, and in
>>  particular, it should not depend on the UA understanding which
>>  language tags are spoken language tags.  It seems to me that a
>>  workable rule is that there is an audio stream and a video stream and
>>  they specify exactly the same language tag in their respective
>>  humintlang attributes.  In that case, it is a request for a spoken
>>  language with simultaneous video of the speaker, and those requests
>>  should be considered satisfied only if both streams can be
>>  established.
>>
>
> The offending text that was in 5.2 and 5.4 was deleted.
>
> The only remaining text that even mentions the issue is Section 5.4:
>
>    The behavior when specifying a non-signed language tag for a video
>    media stream, or a signed language tag for an audio or text media
>    stream, is not defined in this document.
>
>    The problem of knowing which language tags are signed and which are
>    not is out of scope of this document.
>
> So, let's delete Section 5.4 and be done with it.  Neither of the
> statements is necessary.
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Make it right before you make it faster.
>

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


"So let's delete Section 5.4 and be done wit=
h it.=C2=A0 Neither of the statements is necessary."=C2=A0
<=
br>
[BA]=C2=A0 I agree that Section 5.4 does not add much value a=
s it stands.=C2=A0=C2=A0

"Non-signed" is=
 not used outside of Section 5.4, so there would not appear to be a need to=
 define it if Section 5.4 were to be deleted.=C2=A0=C2=A0

However, the term "signed" is used in 7 other places in t=
he document other than in Section 5.4.

So we may n=
eed to find a reference to define that term.=C2=A0

If Gunnar's suggested definition can be confirmed,=C2=A0 this might be=
 as simple as adding a reference to the IANA language tag repository.=C2=A0=


On Su=
n, Nov 19, 2017 at 3:52 PM, Randall Gellens <rg+ietf@randy.pensi=
ve.org> wrote:
My view of i=
ssue #43 remains that we do not need to specify a mechanism for determining=
 which tags are signed.=C2=A0 In the email discussion of the past month or =
so, I fear we are drifting into adding complexity rather than removing it.=
=C2=A0 I think the way forward is to keep this document as simple as possib=
le.=C2=A0 As Bernard notes in his email of 10/23, there is no benefit in th=
is case of explicitly saying that certain things are not defined.=C2=A0 Sin=
ce the document does not define them, they are undefined in the document.


At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:



=C2=A0In other words,it is not clear to me how Section 5.4's discussion=
 of scope improves or clarifies the situation in any way - and there is som=
e possibility that it could cause problems.







I believe comment #43 should be closed as no longer applicable, since the t=
ext against which it was generated has been deleted.=C2=A0 (I've said t=
his before, and I believe it remains the case.)



The comment from which #43 derives was made against a version of the docume=
nt that had text explicitly discussing signed versus unsigned tags.=C2=A0 T=
hat text was subsequently deleted.



Here is the comment from which #43 derived:





=C2=A0 =C2=A0 5.2.=C2=A0 New 'humintlang-send' and 'humintlang-=
recv' attributes



=C2=A0 =C2=A0 Note that while signed language tags are used with a video st=
ream

=C2=A0to

=C2=A0 =C2=A0 indicate sign language, a spoken language tag for a video str=
eam

=C2=A0in

=C2=A0 =C2=A0 parallel with an audio stream with the same spoken language t=
ag

=C2=A0 =C2=A0 indicates a request for a supplemental video stream to see th=
e

=C2=A0 =C2=A0 speaker.



=C2=A0And there's a similar paragraph in 5.4:





=C2=A0 =C2=A0 A spoken language tag for a video stream in conjunction with =
an



=C2=A0audio



=C2=A0 =C2=A0 stream with the same language might indicate a request for
=C2=A0 =C2=A0 supplemental video to see the speaker.





=C2=A0I think this mechanism needs to be described more exactly, and in

=C2=A0particular, it should not depend on the UA understanding which

=C2=A0language tags are spoken language tags.=C2=A0 It seems to me that a
=C2=A0workable rule is that there is an audio stream and a video stream and=


=C2=A0they specify exactly the same language tag in their respective

=C2=A0humintlang attributes.=C2=A0 In that case, it is a request for a spok=
en

=C2=A0language with simultaneous video of the speaker, and those requests
=C2=A0should be considered satisfied only if both streams can be

=C2=A0established.





The offending text that was in 5.2 and 5.4 was deleted.



The only remaining text that even mentions the issue is Section 5.4:



=C2=A0 =C2=A0The behavior when specifying a non-signed language tag for a v=
ideo

=C2=A0 =C2=A0media stream, or a signed language tag for an audio or text me=
dia

=C2=A0 =C2=A0stream, is not defined in this document.



=C2=A0 =C2=A0The problem of knowing which language tags are signed and whic=
h are

=C2=A0 =C2=A0not is out of scope of this document.



So, let's delete Section 5.4 and be done with it.=C2=A0 Neither of the =
statements is necessary.



-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

Make it right before you make it faster.





--001a1143dd5a102e6d055e61f35d--


From nobody Mon Nov 20 06:55: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 26183129AA8 for ; Mon, 20 Nov 2017 06:55:17 -0800 (PST)
X-Quarantine-ID: <0HaAO4cCUHSd>
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.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0HaAO4cCUHSd for ; Mon, 20 Nov 2017 06:55:15 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3DA129AB6 for ; Mon, 20 Nov 2017 06:55:15 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 20 Nov 2017 06:55:20 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:   
X-Mailer: Eudora for Mac OS X
Date: Mon, 20 Nov 2017 06:55:11 -0800
To: Bernard Aboba 
From: Randall Gellens 
Cc: slim@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 14:55:17 -0000

At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:

>  "So let's delete Section 5.4 and be done with it.  Neither of the 
> statements is necessary."
>
>  [BA]  I agree that Section 5.4 does not add much value as it stands.
>
>  "Non-signed" is not used outside of Section 5.4, so there would not 
> appear to be a need to define it if Section 5.4 were to be deleted.
>
>  However, the term "signed" is used in 7 other places in the 
> document other than in Section 5.4.

But none of those instances are normative.

>  So we may need to find a reference to define that term.

Because the uses of the term are descriptive and mostly background, I 
do not think we need to add a definition or even a reference to a 
definition of the term.

--Randall

>
>  If Gunnar's suggested definition can be confirmed,  this might be 
> as simple as adding a reference to the IANA language tag repository.
>
>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens 
> <rg+ietf@randy.pensive.org> wrote:
>
>  My view of issue #43 remains that we do not need to specify a 
> mechanism for determining which tags are signed.  In the email 
> discussion of the past month or so, I fear we are drifting into 
> adding complexity rather than removing it.  I think the way forward 
> is to keep this document as simple as possible.  As Bernard notes 
> in his email of 10/23, there is no benefit in this case of 
> explicitly saying that certain things are not defined.  Since the 
> document does not define them, they are undefined in the document.
>
>  At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>
>   In other words,it is not clear to me how Section 5.4's discussion 
> of scope improves or clarifies the situation in any way - and there 
> is some possibility that it could cause problems.
>
>
>
>  I believe comment #43 should be closed as no longer applicable, 
> since the text against which it was generated has been deleted. 
> (I've said this before, and I believe it remains the case.)
>
>  The comment from which #43 derives was made against a version of 
> the document that had text explicitly discussing signed versus 
> unsigned tags.  That text was subsequently deleted.
>
>  Here is the comment from which #43 derived:
>
>      5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>      Note that while signed language tags are used with a video stream
>   to
>      indicate sign language, a spoken language tag for a video stream
>   in
>      parallel with an audio stream with the same spoken language tag
>      indicates a request for a supplemental video stream to see the
>      speaker.
>
>   And there's a similar paragraph in 5.4:
>
>      A spoken language tag for a video stream in conjunction with an
>
>   audio
>
>      stream with the same language might indicate a request for
>      supplemental video to see the speaker.
>
>
>   I think this mechanism needs to be described more exactly, and in
>   particular, it should not depend on the UA understanding which
>   language tags are spoken language tags.  It seems to me that a
>   workable rule is that there is an audio stream and a video stream and
>   they specify exactly the same language tag in their respective
>   humintlang attributes.  In that case, it is a request for a spoken
>   language with simultaneous video of the speaker, and those requests
>   should be considered satisfied only if both streams can be
>   established.
>
>
>  The offending text that was in 5.2 and 5.4 was deleted.
>
>  The only remaining text that even mentions the issue is Section 5.4:
>
>     The behavior when specifying a non-signed language tag for a video
>     media stream, or a signed language tag for an audio or text media
>     stream, is not defined in this document.
>
>     The problem of knowing which language tags are signed and which are
>     not is out of scope of this document.
>
>  So, let's delete Section 5.4 and be done with it.  Neither of the 
> statements is necessary.
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  Make it right before you make it faster.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You see, wire telegraph is a kind of very, very long cat.  You
pull his tail in New York and his head is meowing in Los Angeles.
Do you understand this?  And radio operates in exactly the same
way: you send signals here, they receive them there.  The only
difference is that there is no cat.            --Albert Einstein


From nobody Mon Nov 20 08:08:02 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 4151E1294A3 for ; Mon, 20 Nov 2017 08:08:00 -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 2PV150sQ2H0s for ; Mon, 20 Nov 2017 08:07:56 -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 6D789129B1D for ; Mon, 20 Nov 2017 08:07:54 -0800 (PST)
X-Halon-ID: ecd2c2cc-ce0c-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id ecd2c2cc-ce0c-11e7-96ae-005056917f90; Mon, 20 Nov 2017 17:07:37 +0100 (CET)
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
To: "Phillips, Addison" , Bernard Aboba 
Cc: "slim@ietf.org" 
References:  <6ebf2b8a-8699-27c1-87af-41acab4cb940@omnitor.se>  
Message-ID: 
Date: Mon, 20 Nov 2017 17:07:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------79230663AB024BEAA48745C9"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 16:08:00 -0000

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

Addison, thanks for guidance,

Den 2017-11-20 kl. 00:07, skrev Phillips, Addison:
>
> A few points.
>
> 1.Sign languages do not necessarily use the subtag ‘sgn’. In fact, 
> most sign languages have subtags that have nothing to do with the 
> ‘sgn’ subtag. They are not ‘extlang’ and do not have a macrolanguage 
> of ‘sgn’. For example, here is the record for American Sign Language:
>
> %%
>
> Type: language
>
> Subtag: ase
>
> Description: American Sign Language
>
> Added: 2009-07-29
>
> %%
>
But all sign languages appear again in the registry registered as 
type "extlang" with Prefix value "sgn"
e.g. for American Sign Language :

%%
Type: extlang
Subtag: ase
Description: American Sign Language
Added: 2009-07-29
Preferred-Value: ase
Prefix: sgn
%%

Therefore the procedure to assess if a language is a sign language I 
have proposed is to search the registry for this combination. The 
procedure could be formalized to use the recommendations about "extlang 
form" described in RFC 5646 section 4.5 on canonicalization (not for 
sending the tag, but when evaluating a tag).

> 2.Sign languages may have the words “Sign Language” in one of their 
> Description fields (notice that I say “one of”). I’m not sure that all 
> sign languages have this. Someone would have to ask the ISO 639 folks 
> if there are any outliers.
>
Yes, but the rule about Prefix: sgn above is much more suitable for 
use in a procedure for finding out the modality. The description string 
could possibly just be used when telling the human parties what the 
result of the negotiation was.
>
> 3.Suppress-Script is an advisory field in the registry. It does not 
> cause or require that the script subtag be omitted. It is also an 
> incomplete bit of documentation: many languages that fit the criteria 
> for Suppress-Script do not have the field in the registry. Use or 
> non-use of the script subtag is not a very reliable indicator of 
> language modality on its own. Tags like “en-US” or “de” function well 
> for identifying the language of various materials and I caution folks 
> that, in my experience, arcane rules about the specialized use of 
> subtags are likely to be ignored.
>
> Overall, my suggestion would be: if you need to deal with modality, 
> don’t use (existing) language subtags for it. Encode metadata to make 
> things explicit. Use private use subtags or an extension for it if you 
> must. But don’t provide super-special meaning for subtags. Personally, 
> I tend to think you should encode modality on a different level. 
> Someone who is hard of hearing and low vision has different needs from 
> a blind user who has different needs from a deaf person with limited 
> mobility… etc.
>
From the discussion above, we can distinguish sign languages, and 
thereby signed modality without using any extra subtags in the attributes.

But we cannot reliably distinguish between the sound of spoken language 
and a view of a speaking person without applying more subtle indications 
like what media subtypes there are specified etc, and that carries us 
too far away from the request in issue #43 to have a simple way for 
applications to assess the modality.

So, in summary, I suggest that we in section 5.4 describe:
1. The three obvious cases:  written modality  in text media, spoken in 
audio and signed in video ( including an indication on how sign language 
is identified.)
I think it is important to make the reader aware of that it is only for 
these three obvious cases that we have a solution, and that justifies a 
place for section 5.4 but with far less detail than my latest proposal.

2.  Tell that other cases can be defined in specific applications or by 
further work.



Thanks,
Gunnar
>
> Addison
>
> *From:*SLIM [mailto:slim-bounces@ietf.org] *On Behalf Of *Bernard Aboba
> *Sent:* Saturday, November 18, 2017 9:25 PM
> *To:* Gunnar Hellström 
> *Cc:* slim@ietf.org
> *Subject:* Re: [Slim] Moving forward on 
> draft-ietf-slim-negotiating-human-language
>
> Gunnar said:
>
> "I earlier thought that an application needed to look into the 
> language subtag Description to find the word "sign" there in the text 
> string. That is not a good solution."
>
> [BA] Agreed. Also, as indicated in RFC 5646 Section 4.1.2 and the IANA 
> registry 
> (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), 
> sign languages may not have always have a subtag of 'sgn':
>
>    Sign languages share a mode of communication rather than a linguistic
>    heritage.  There are many sign languages that have developed
>    independently, and the subtag 'sgn' indicates only the presence of a
>    sign language.  A number of sign languages also had grandfathered
>    tags registered for them during the RFC 3066 
>  era.  For example, the
>    grandfathered tag "sgn-US" was registered to represent 'American Sign
>    Language' specifically, without reference to the United States.  This
>    is still valid, but deprecated: a document in American Sign Language
>    can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the
>    language called 'American Sign Language').
>
> Gunnar also said:
>
> "A specific sign language can be identified by its existence in the IANA
> registry of language subtags according to BCP 47 [RFC5646] , and finding
> that the language subtag is found at least in two entries in the
> registry, once with the Type field "language" and once with the Type
> field "extlang" combined with the Prefix field value "sgn".
>
> So that should be the response on Dales request to easily decide if a 
> language tag is for a sign language. "
>
> [BA]  Looking at the IANA registry, having a Type field "extlang" 
> combined with the Prefix field value 'sgn' seems to be used as an 
> indicator of a sign language.  Do you think we can rely on this? 
> Currently this is only a SHOULD  in RFC 5646 Section 3.4:
>
>             3.  Sign languages SHOULD have an 'extlang' record with 
> an'Prefix' of 'sgn'.
> "My wording proposal starts with the obvious cases: a non-signed 
> language tag in audio media is spoken, and a non-signed language tag 
> in text media is written."
> [BA] Assuming your suggested approach allows us to reliably determine 
> non-sign languages, this seems solid.
> Gunnar further said:
> "But for other cases, like in video or message or application or 
> multiplexed media, other indications must be used to
> understand the intended modality... I wish for the ambiguous cases we 
> could use the script subtag -zxxx to indicate
> spoken modality and a real script subtag..."
> [BA] This is where I become uneasy, because without an explicit 
> mechanism such as script subtags, there is the potential for ambiguity.
> Trying to address reduce that ambiguity via heuristics could turn out 
> to be a bad idea, compared with proceeding more cautiously
> by leaving behavior undefined for now and revisiting the situation 
> later when we understand the problem better. For example:
> "Use for sending of a visual view of a speaking person may be 
> indicated by the value "speaker" in an SDP
> Content attribute according to RFC 4796 [RFC4796] in a "video" media 
> stream or another media carrying video (e.g. "message" or "application")."
> [BA] There are quite a few potential corner cases here. For example, 
> if "en-US" language is included in an offer within a video m-line, 
> should the answerer assume this implies a willingness to lip read US 
> English if the value "speaker" is in the Content attribute?  What can 
> be assumed if a value other than "speaker" is in the Content 
> attribute? Might that represent something entirely different, such as 
> the desire to receive captioning in US English? If so, how could the 
> Offerer indicate both the capability of lipreading and the ability to 
> handle captions? And what happens if the Answerer doesn't mimic the 
> Content attribute in the Offer? Seems like there are some potential 
> "gotchas" here.
> "Use of written modality in another media stream than
> "text", may be discriminated by use of a script subtag in the language
> tag, where that is appropriate."
> [BA] What if the language in question has script subtags suppressed? 
> What if the Offerer includes a script subtag in the video m-line but 
> also "speaker" in the Content attribute? Again, there could be quite a 
> few corner cases lurking here.
>
> On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellström 
> > wrote:
>
>     Thanks Bernard for pushing for closing the last open issue.
>
>     Den 2017-11-18 kl. 19:46, skrev Bernard Aboba:
>
>         At this point, only a single Issue (43) remains open on
>         draft-ietf-slim-negotiating-human-language::
>
>         https://trac.ietf.org/trac/slim/ticket/43
>
>         This relates to the modality of a language indication.
>
>         Currently, Gunnar has suggested a modification to the text of
>         Section 5.4 in order to address the issue:
>
>         https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g
>
>         Can WG participants review this suggested change, so that we
>         can determine how to move forward?
>
>         Currently, Section 5.4 states that:
>
>            The problem of knowing which language tags are signed and
>         which are
>
>            not is out of scope of this document.
>
>     I earlier thought that an application needed to look into the
>     language subtag Description to find the word "sign" there in the
>     text string. That is not a good solution. But when studying the
>     topic again in RFC 5646 I found that there is a consistent
>     machine-implementable way to assess if a language subtag is for a
>     sign language.
>     Therefore I included this text in the latest proposal for section
>     5.4 at the link that Bernard provided:
>
>     "
>
>     A specific sign language can be identified by its existence in the
>     IANA
>
>     registry of language subtags according to BCP 47 [RFC5646] , and
>     finding
>
>     that the language subtag is found at least in two entries in the
>
>     registry, once with the Type field "language" and once with the Type
>
>     field "extlang" combined with the Prefix field value "sgn".
>
>     "
>
>     So that should be the response on Dales request to easily decide
>     if a language tag is for a sign language.
>
>     Worse is next topic in issue 43: to assess if a language tag is
>     for a spoken modality or written modality of a language.
>     My wording proposal starts with the obvious cases: a non-signed
>     languge tag in audio media is spoken, and a non-signed language
>     tag in text media is written. But for other cases, like in video
>     or message or application or multiplexed media, other indications
>     must be used to understand the intended modality. The proposed
>     text mentions a few, and leaves to applications to decide which
>     mechanisms to use for such cases. I wish we for the ambiguous
>     cases could use the script subtag -zxxx to indicate spoken
>     modality and a real script subtag even on language subtags where
>     script subtags are suppressed, because that would satisfy issue 43
>     nicely and make section 5.4 much shorter and clearer. But we have
>     had resistance against that solution.
>
>     The proposed text might be a bit long and detailed. I am prepared
>     to agree on a shortened version if there are any proposals. I
>     think though that contents of 5.4 in the direction of my proposal
>     is what satisfies  issue 43 and also the comments lately that
>     section 5.4 is too restrictive.
>
>     /Gunnar
>
>
>         _______________________________________________
>
>         SLIM mailing list
>
>         SLIM@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/slim
>
>
>
>     -- 
>
>     -----------------------------------------
>
>     Gunnar Hellström
>
>     Omnitor
>
>     gunnar.hellstrom@omnitor.se 
>
>     +46 708 204 288
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------79230663AB024BEAA48745C9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Addison, thanks for guidance,

    

    
Den 2017-11-20 kl. 00:07, skrev
      Phillips, Addison:

    

    

      
      
      
      

        
A
            few points.

        
 

        
1.       Sign
            languages do not necessarily use the subtag ‘sgn’. In fact,
            most sign languages have subtags that have nothing to do
            with the ‘sgn’ subtag. They are not ‘extlang’ and do not
            have a macrolanguage of ‘sgn’. For example, here is the
            record for American Sign Language:

        
 

        
%%

        
Type:
            language

        
Subtag:
            ase

        
Description:
            American Sign Language

        
Added:
            2009-07-29

        
%%

        
 

      

    

    <GH>But all sign languages appear again in the registry
    registered as type "extlang" with Prefix value "sgn"

    e.g. for American Sign Language :

    

    
%%
Type: extlang
Subtag: ase
Description: American Sign Language
Added: 2009-07-29
Preferred-Value: ase
Prefix: sgn
%%



    Therefore the procedure to assess if a language is a sign language I
    have proposed is to search the registry for this combination. The
    procedure could be formalized to use the recommendations about
    "extlang form" described in RFC 5646 section 4.5 on canonicalization
    (not for sending the tag, but when evaluating a tag).  

    

    

      

        
 

        
2.       Sign
            languages may have the words “Sign Language” in one of their
            Description fields (notice that I say “one of”). I’m not
            sure that all sign languages have this. Someone would have
            to ask the ISO 639 folks if there are any outliers.

      

    

    <GH>Yes, but the rule about Prefix: sgn above is much more
    suitable for use in a procedure for finding out the modality. The
    description string could possibly just be used when telling the
    human parties what the result of the negotiation was. 

    

      

        

        
3.       Suppress-Script
            is an advisory field in the registry. It does not cause or
            require that the script subtag be omitted. It is also an
            incomplete bit of documentation: many languages that fit the
            criteria for Suppress-Script do not have the field in the
            registry. Use or non-use of the script subtag is not a very
            reliable indicator of language modality on its own. Tags
            like “en-US” or “de” function well for identifying the
            language of various materials and I caution folks that, in
            my experience, arcane rules about the specialized use of
            subtags are likely to be ignored.

      

    

    

      

        

        
 

        
Overall,
            my suggestion would be: if you need to deal with modality,
            don’t use (existing) language subtags for it. Encode
            metadata to make things explicit. Use private use subtags or
            an extension for it if you must. But don’t provide
            super-special meaning for subtags. Personally, I tend to
            think you should encode modality on a different level.
            Someone who is hard of hearing and low vision has different
            needs from a blind user who has different needs from a deaf
            person with limited mobility… etc. 

      

    

    <GH>From the discussion above, we can distinguish sign
    languages, and thereby signed modality without using any extra
    subtags in the attributes.

    

    But we cannot reliably distinguish between the sound of spoken
    language and a view of a speaking person without applying more
    subtle indications like what media subtypes there are specified etc,
    and that carries us too far away from the request in issue #43 to
    have a simple way for applications to assess the modality.  

    

    So, in summary, I suggest that we in section 5.4 describe:

    1. The three obvious cases:  written modality  in text media, spoken
    in audio and signed in video ( including an indication on how sign
    language is identified.)

    I think it is important to make the reader aware of that it is only
    for these three obvious cases that we have a solution, and that
    justifies a place for section 5.4 but with far less detail than my
    latest proposal.

    

    2.  Tell that other cases can be defined in specific applications or
    by further work.  

    

    

    

    Thanks,

    Gunnar

    

      

        

        
 

        
Addison

        
 

        

          

            

              
From:
                  SLIM [mailto:slim-bounces@ietf.org]
                  On Behalf Of Bernard Aboba

                  Sent: Saturday, November 18, 2017 9:25 PM

                  To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>

                  Cc: slim@ietf.org

                  Subject: Re: [Slim] Moving forward on
                  draft-ietf-slim-negotiating-human-language

            

          

          
 

          

            
Gunnar said: 

            

              
 

            

            

              
"I
                  earlier thought that an application needed to look
                  into the language subtag Description to find the word
                  "sign" there in the text string. That is not a good
                  solution."

            

            

              
 

            

            

              
[BA] Agreed. Also, as indicated in
                RFC 5646 Section 4.1.2 and the IANA registry (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry),
                sign languages may not have always have a subtag of
                'sgn': 

            

            

              
 

            

            

              
   Sign languages share a mode of communication rather than a linguistic

              
   heritage.  There are many sign languages that have developed

              
   independently, and the subtag 'sgn' indicates only the presence of a

              
   sign language.  A number of sign languages also had grandfathered

              
   tags registered for them during the RFC 3066 era.  For example, the

              
   grandfathered tag "sgn-US" was registered to represent 'American Sign

              
   Language' specifically, without reference to the United States.  This

              
   is still valid, but deprecated: a document in American Sign Language

              
   can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the

              
   language called 'American Sign Language').

            

            

              
 

            

            

              
Gunnar also said: 

            

            

              
 

            

            

              
"A specific sign language can be identified by its existence in the IANA 

              
registry of language subtags according to BCP 47 [RFC5646] , and finding 

              
that the language subtag is found at least in two entries in the 

              
registry, once with the Type field "language" and once with the Type 

              
field "extlang" combined with the Prefix field value "sgn".

              

                
 

              

              

                
So
                    that should be the response on Dales request to
                    easily decide if a language tag is for a sign
                    language. "

              

              

                
 

              

              

                
[BA]  Looking at the IANA registry,
                  having a Type field "extlang" combined with the Prefix
                  field value 'sgn' seems to be used as an indicator of
                  a sign language.  Do you think we can rely on this?
                  Currently this is only a SHOULD  in RFC 5646 Section
                  3.4: 

              

              

                

                  
 

                

                

                  
            3.  Sign languages SHOULD have an 'extlang' record with an'Prefix' of 'sgn'.

                  
 

                  
 

                  
"My wording proposal starts with the obvious cases: a non-signed language tag in audio media is spoken, and a non-signed language tag in text media is written."

                  
 

                  
[BA] Assuming your suggested approach allows us to reliably determine non-sign languages, this seems solid. 

                  
 

                  
Gunnar further said: 

                  
 

                  
"But for other cases, like in video or message or application or multiplexed media, other indications must be used to 

                  
understand the intended modality... I wish for the ambiguous cases we could use the script subtag -zxxx to indicate

                  
spoken modality and a real script subtag..."

                  
 

                  
[BA] This is where I become uneasy, because without an explicit mechanism such as script subtags, there is the potential for ambiguity.

                  
Trying to address reduce that ambiguity via heuristics could turn out to be a bad idea, compared with proceeding more cautiously 

                  
by leaving behavior undefined for now and revisiting the situation later when we understand the problem better. For example: 

                  
 

                  
"Use for sending of a visual view of a speaking person may be indicated by the value "speaker" in an SDP 

                  
Content attribute according to RFC 4796 [RFC4796] in a "video" media stream or another media carrying video (e.g. "message" or "application")."

                  
[BA] There are quite a few potential corner cases here. For example, if "en-US" language is included in an offer within a video m-line, should the answerer assume this implies a willingness to lip read US English if the value "speaker" is in the Content attribute?  What can be assumed if a value other than "speaker" is in the Content attribute? Might that represent something entirely different, such as the desire to receive captioning in US English? If so, how could the Offerer indicate both the capability of lipreading and the ability to handle captions? And what happens if the Answerer doesn't mimic the Content attribute in the Offer? Seems like there are some potential "gotchas" here.

                  
"Use of written modality in another media stream than 

                  
"text", may be discriminated by use of a script subtag in the language 

                  
tag, where that is appropriate."

                  
[BA] What if the language in question has script subtags suppressed? What if the Offerer includes a script subtag in the video m-line but also "speaker" in the Content attribute? Again, there could be quite a few corner cases lurking here. 

                  
 

                  
 

                  
 

                  
 

                  
 

                  
 

                  
 

                  
 

                

              

            

          

          

            
 

            

              
On Sat, Nov 18, 2017 at 2:33 PM,
                Gunnar Hellström <gunnar.hellstrom@omnitor.se>
                wrote:

              

                

                  
Thanks Bernard for pushing for
                    closing the last open issue.  

                  

                    

                      
Den 2017-11-18 kl. 19:46,
                        skrev Bernard Aboba:

                        

                        

                      

                        

                          
At this point, only a
                            single Issue (43) remains open on
                            draft-ietf-slim-negotiating-human-language:: 
                            

                          
                          

                            
 

                          

                          

                            
This relates to the
                              modality of a language indication. 

                          

                          

                            
 

                          

                          

                            
Currently, Gunnar has
                              suggested a modification to the text of
                              Section 5.4 in order to address the
                              issue: 

                          

                          
                          

                            
 

                          

                          

                            
 

                          

                          

                            
Can WG participants
                              review this suggested change, so that we
                              can determine how to move forward? 

                          

                          

                            
 

                          

                          

                            
Currently, Section 5.4
                              states that: 

                          

                          

                            
 

                          

                          

                            
   The problem of knowing which language tags are signed and which are

                            
   not is out of scope of this document.

                          

                        

                      

                    

                  

                  
I earlier thought that an
                    application needed to look into the language subtag
                    Description to find the word "sign" there in the
                    text string. That is not a good solution. But when
                    studying the topic again in RFC 5646 I found that
                    there is a consistent machine-implementable way to
                    assess if a language subtag is for a sign language.
                    

                    Therefore I included this text in the latest
                    proposal for section 5.4 at the link that Bernard
                    provided:

                    

                    " 

                  
A specific sign language can be identified by its existence in the IANA 

                  
registry of language subtags according to BCP 47 [RFC5646] , and finding 

                  
that the language subtag is found at least in two entries in the 

                  
registry, once with the Type field "language" and once with the Type 

                  
field "extlang" combined with the Prefix field value "sgn".

                  
"

                    

                    So that should be the response on Dales request to
                    easily decide if a language tag is for a sign
                    language. 

                    

                    Worse is next topic in issue 43: to assess if a
                    language tag is for a spoken modality or written
                    modality of a language.

                    My wording proposal starts with the obvious cases: a
                    non-signed languge tag in audio media is spoken, and
                    a non-signed language tag in text media is written. 
                    But for other cases, like in video or message or
                    application or multiplexed media, other indications
                    must be used to understand the intended modality.
                    The proposed text mentions a few, and leaves to
                    applications to decide which mechanisms to use for
                    such cases. I wish we for the ambiguous cases could
                    use the script subtag -zxxx to indicate spoken
                    modality and a real script subtag even on language
                    subtags where script subtags are suppressed, because
                    that would satisfy issue 43 nicely and make section
                    5.4 much shorter and clearer. But we have had
                    resistance against that solution. 

                    

                    The proposed text might be a bit long and detailed.
                    I am prepared to agree on a shortened version if
                    there are any proposals. I think though that
                    contents of 5.4 in the direction of my proposal is
                    what satisfies  issue 43 and also the comments
                    lately that section 5.4 is too restrictive. 

                    

                    /Gunnar

                     

                    

                      

                  

                    
 

                    
_______________________________________________

                    
SLIM mailing list

                    
SLIM@ietf.org

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

                  

                  


                      

                      

                  
-- 

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

                  
Gunnar Hellström

                  
Omnitor

                  
gunnar.hellstrom@omnitor.se

                  
+46 708 204 288

                

              

            

            
 

          

        

      

      

      

      

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


    

    

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

  


--------------79230663AB024BEAA48745C9--


From nobody Mon Nov 20 09:25: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 223D6129C6A for ; Mon, 20 Nov 2017 09:25:19 -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 eUag8UHUtSWs for ; Mon, 20 Nov 2017 09:25:17 -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 C2F73129C64 for ; Mon, 20 Nov 2017 09:25:16 -0800 (PST)
X-Halon-ID: bcef8363-ce17-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id bcef8363-ce17-11e7-96ae-005056917f90; Mon, 20 Nov 2017 18:25:01 +0100 (CET)
To: Randall Gellens , Bernard Aboba 
Cc: slim@ietf.org
References:    
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
Date: Mon, 20 Nov 2017 18:25:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A0CEFFAEF362D3151E4EF8C0"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 17:25:19 -0000

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

It is not the signed languages that are causing the problem. It is the 
spoken and written, when used in other media than the obvious audio and 
text media.

And we should specify what is obvious and well defined and not, so here 
is a new shorter proposal for section 5.4.

-----Old text----


      5.4 Undefined Combinations



    The behavior when specifying a non-signed language tag for a video
    media stream, or a signed language tag for an audio or text media
    stream, is not defined in this document.

    The problem of knowing which language tags are signed and which are
    not is out of scope of this document.

-----New text------------
5.4 Media, Language and Modality indications

The combination of Language tags and other information in the media 
descriptions should be composed so that the intended modality can be 
concluded by the negotiating parties. The following combinations of 
language tags and media provide obvious information about the modality: 
sign language tags in video media indicate signed modality, spoken 
language tags for audio media indicate spoken modality and written 
language tags for text media indicate written modality. The examples in 
this specification are all from this set of three obvious 
language/media/modality combinations.

A sign language can be identified by the existence in the IANA registry 
of language subtags according to BCP 47 [RFC5646] of the language subtag 
with the Type field "extlang" combined with the Prefix field value "sgn".
A specific spoken or written language can be identified by not having 
any such "sgn" Prefix.

Use of language may appear in other media, such as "message" and 
"application". Video media may be used for other modalities than signed. 
Such use may be supported by further work or application specific 
agreements or indications for evaluation of the intended modality.

-------------------------------------------------------------------End 
of new text---------------------------------------
Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
> At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>
>> "So let's delete Section 5.4 and be done with it. Neither of the 
>> statements is necessary."
>>
>> [BA] I agree that Section 5.4 does not add much value as it stands.
>>
>> "Non-signed" is not used outside of Section 5.4, so there would not 
>> appear to be a need to define it if Section 5.4 were to be deleted.
>>
>> However, the term "signed" is used in 7 other places in the document 
>> other than in Section 5.4.
>
> But none of those instances are normative.
>
>> So we may need to find a reference to define that term.
>
> Because the uses of the term are descriptive and mostly background, I 
> do not think we need to add a definition or even a reference to a 
> definition of the term.
>
> --Randall
>
>>
>> If Gunnar's suggested definition can be confirmed, this might be as 
>> simple as adding a reference to the IANA language tag repository.
>>
>> On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens 
>> <rg+ietf@randy.pensive.org> wrote:
>>
>> My view of issue #43 remains that we do not need to specify a 
>> mechanism for determining which tags are signed. In the email 
>> discussion of the past month or so, I fear we are drifting into 
>> adding complexity rather than removing it. I think the way forward 
>> is to keep this document as simple as possible. As Bernard notes in 
>> his email of 10/23, there is no benefit in this case of explicitly 
>> saying that certain things are not defined. Since the document does 
>> not define them, they are undefined in the document.
>>
>> At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>
>>  In other words,it is not clear to me how Section 5.4's discussion 
>> of scope improves or clarifies the situation in any way - and there 
>> is some possibility that it could cause problems.
>>
>>
>>
>> I believe comment #43 should be closed as no longer applicable, 
>> since the text against which it was generated has been deleted. (I've 
>> said this before, and I believe it remains the case.)
>>
>> The comment from which #43 derives was made against a version of the 
>> document that had text explicitly discussing signed versus unsigned 
>> tags. That text was subsequently deleted.
>>
>> Here is the comment from which #43 derived:
>>
>>  5.2. New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>  Note that while signed language tags are used with a video stream
>>  to
>>  indicate sign language, a spoken language tag for a video stream
>>  in
>>  parallel with an audio stream with the same spoken language tag
>>  indicates a request for a supplemental video stream to see the
>>  speaker.
>>
>>  And there's a similar paragraph in 5.4:
>>
>>  A spoken language tag for a video stream in conjunction with an
>>
>>  audio
>>
>>  stream with the same language might indicate a request for
>>  supplemental video to see the speaker.
>>
>>
>>  I think this mechanism needs to be described more exactly, and in
>>  particular, it should not depend on the UA understanding which
>>  language tags are spoken language tags. It seems to me that a
>>  workable rule is that there is an audio stream and a video stream and
>>  they specify exactly the same language tag in their respective
>>  humintlang attributes. In that case, it is a request for a spoken
>>  language with simultaneous video of the speaker, and those requests
>>  should be considered satisfied only if both streams can be
>>  established.
>>
>>
>> The offending text that was in 5.2 and 5.4 was deleted.
>>
>> The only remaining text that even mentions the issue is Section 5.4:
>>
>>  The behavior when specifying a non-signed language tag for a video
>>  media stream, or a signed language tag for an audio or text media
>>  stream, is not defined in this document.
>>
>>  The problem of knowing which language tags are signed and which are
>>  not is out of scope of this document.
>>
>> So, let's delete Section 5.4 and be done with it. Neither of the 
>> statements is necessary.
>>
>> --
>> Randall Gellens
>> Opinions are personal; facts are suspect; I speak for myself only
>> -------------- Randomly selected tag: ---------------
>> Make it right before you make it faster.
>
>

-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


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


  
    
  
  
    
It is not the signed languages that are causing the problem. It
      is the spoken and written, when used in other media than the
      obvious audio and text media. 

    

    
And we should specify what is obvious and well defined and not,
      so here is a new shorter proposal for section 5.4.

    
-----Old text----

    
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


    -----New text------------

    5.4 Media, Language and Modality indications

    

    The combination of Language tags and other information in the media
    descriptions should be composed so that the intended modality can be
    concluded by the negotiating parties. The following combinations of
    language tags and media provide obvious information about the
    modality: sign language tags in video media indicate signed
    modality, spoken language tags for audio media indicate spoken
    modality and written language tags for text media indicate written
    modality. The examples in this specification are all from this set
    of three obvious language/media/modality combinations.

    

    A sign language can be identified by the existence in the IANA
    registry of language subtags according to BCP 47 [RFC5646] of the
    language subtag with the Type field "extlang" combined with the
    Prefix field value "sgn". 

    A specific spoken or written language can be identified by not
    having any such "sgn" Prefix.

    

    Use of language may appear in other media, such as "message" and
    "application". Video media may be used for other modalities than
    signed. Such use may be supported by further work or application
    specific agreements or indications for evaluation of the intended
    modality. 

    

-------------------------------------------------------------------End
    of new text---------------------------------------

    
Den 2017-11-20 kl. 15:55, skrev Randall
      Gellens:

    

    
At 7:47 PM -0800
      11/19/17, Bernard Aboba wrote:
      

      

      
"So let's delete Section 5.4 and be done
        with it. Neither of the statements is necessary."
        

        

        [BA] I agree that Section 5.4 does not add much value as it
        stands.
        

        

        "Non-signed" is not used outside of Section 5.4, so there would
        not appear to be a need to define it if Section 5.4 were to be
        deleted.
        

        

        However, the term "signed" is used in 7 other places in the
        document other than in Section 5.4.
        

      

      

      But none of those instances are normative.
      

      

      
So we may need to find a reference to
        define that term.
        

      

      

      Because the uses of the term are descriptive and mostly
      background, I do not think we need to add a definition or even a
      reference to a definition of the term.
      

      

      --Randall
      

      

      

        

        If Gunnar's suggested definition can be confirmed, this might
        be as simple as adding a reference to the IANA language tag
        repository.
        

        

        On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
<<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org>
        wrote:
        

        

        My view of issue #43 remains that we do not need to specify a
        mechanism for determining which tags are signed. In the email
        discussion of the past month or so, I fear we are drifting into
        adding complexity rather than removing it. I think the way
        forward is to keep this document as simple as possible. As
        Bernard notes in his email of 10/23, there is no benefit in this
        case of explicitly saying that certain things are not defined.
        Since the document does not define them, they are undefined in
        the document.
        

        

        At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
        

        

         In other words,it is not clear to me how Section 5.4's
        discussion of scope improves or clarifies the situation in any
        way - and there is some possibility that it could cause
        problems.
        

        

        

        

        I believe comment #43 should be closed as no longer applicable,
        since the text against which it was generated has been deleted.
        (I've said this before, and I believe it remains the case.)
        

        

        The comment from which #43 derives was made against a version
        of the document that had text explicitly discussing signed
        versus unsigned tags. That text was subsequently deleted.
        

        

        Here is the comment from which #43 derived:
        

        

         5.2. New 'humintlang-send' and 'humintlang-recv'
        attributes
        

        

         Note that while signed language tags are used with a video
        stream
        

         to
        

         indicate sign language, a spoken language tag for a video
        stream
        

         in
        

         parallel with an audio stream with the same spoken language
        tag
        

         indicates a request for a supplemental video stream to see
        the
        

         speaker.
        

        

         And there's a similar paragraph in 5.4:
        

        

         A spoken language tag for a video stream in conjunction
        with an
        

        

         audio
        

        

         stream with the same language might indicate a request for
        

         supplemental video to see the speaker.
        

        

        

         I think this mechanism needs to be described more exactly, and
        in
        

         particular, it should not depend on the UA understanding which
        

         language tags are spoken language tags. It seems to me that a
        

         workable rule is that there is an audio stream and a video
        stream and
        

         they specify exactly the same language tag in their respective
        

         humintlang attributes. In that case, it is a request for a
        spoken
        

         language with simultaneous video of the speaker, and those
        requests
        

         should be considered satisfied only if both streams can be
        

         established.
        

        

        

        The offending text that was in 5.2 and 5.4 was deleted.
        

        

        The only remaining text that even mentions the issue is Section
        5.4:
        

        

         The behavior when specifying a non-signed language tag for a
        video
        

         media stream, or a signed language tag for an audio or text
        media
        

         stream, is not defined in this document.
        

        

         The problem of knowing which language tags are signed and
        which are
        

         not is out of scope of this document.
        

        

        So, let's delete Section 5.4 and be done with it. Neither of
        the statements is necessary.
        

        

        --
        

        Randall Gellens
        

        Opinions are personal; facts are suspect; I speak for
        myself only
        

        -------------- Randomly selected tag: ---------------
        

        Make it right before you make it faster.
        

      

      

      

    

    

    
-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  


--------------A0CEFFAEF362D3151E4EF8C0--


From nobody Mon Nov 20 10:14:37 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 DE9F212E037 for ; Mon, 20 Nov 2017 10:14:35 -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.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HBSuxEhMTGH6 for ; Mon, 20 Nov 2017 10:14:34 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 04FBF129572 for ; Mon, 20 Nov 2017 10:14:34 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 20 Nov 2017 10:14:39 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Mon, 20 Nov 2017 10:14:29 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Bernard Aboba 
From: Randall Gellens 
Cc: slim@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 18:14:36 -0000

At 6:25 PM +0100 11/20/17, Gunnar Hellstr=F6m wrote:

>  It is not the signed languages that are causing=20
> the problem. It is the spoken and written, when=20
> used in other media than the obvious audio and=20
> text media.

I am not convinced that this is a problem that=20
the draft needs to have text for.  As Bernard=20
noted in an earlier email, it doesn't really=20
matter if the draft attempts to limit what can be=20
done.

Let's delete section 5.4, close issue #43, and advance the draft.

--Randall

>
>  And we should specify what is obvious and well=20
> defined and not, so here is a new shorter=20
> proposal for section 5.4.
>
>  -----Old text----
>
>  5.4 Undefined Combinations
>
>
>
>     The behavior when specifying a non-signed language tag for a video
>     media stream, or a signed language tag for an audio or text media
>     stream, is not defined in this document.
>
>     The problem of knowing which language tags are signed and which are
>     not is out of scope of this document.
>   -----New text------------
>  5.4 Media, Language and Modality indications
>
>  The combination of Language tags and other=20
> information in the media descriptions should be=20
> composed so that the intended modality can be=20
> concluded by the negotiating parties. The=20
> following combinations of language tags and=20
> media provide obvious information about the=20
> modality: sign language tags in video media=20
> indicate signed modality, spoken language tags=20
> for audio media indicate spoken modality and=20
> written language tags for text media indicate=20
> written modality. The examples in this=20
> specification are all from this set of three=20
> obvious language/media/modality combinations.
>
>  A sign language can be identified by the=20
> existence in the IANA registry of language=20
> subtags according to BCP 47 [RFC5646] of the=20
> language subtag with the Type field "extlang"=20
> combined with the Prefix field value "sgn".
>  A specific spoken or written language can be=20
> identified by not having any such "sgn" Prefix.
>
>  Use of language may appear in other media, such=20
> as "message" and "application". Video media may=20
> be used for other modalities than signed. Such=20
> use may be supported by further work or=20
> application specific agreements or indications=20
> for evaluation of the intended modality.
>
>=20
> -------------------------------------------------------------------End=20
> of new=20
> text---------------------------------------
>
>  Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>
>>  At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>
>>>  "So let's delete Section 5.4 and be done with=20
>>> it. Neither of the statements is necessary."
>>>
>>>  [BA] I agree that Section 5.4 does not add much value as it stands.
>>>
>>>  "Non-signed" is not used outside of Section=20
>>> 5.4, so there would not appear to be a need=20
>>> to define it if Section 5.4 were to be=20
>>> deleted.
>>>
>>>  However, the term "signed" is used in 7 other=20
>>> places in the document other than in Section=20
>>> 5.4.
>>>
>>
>>  But none of those instances are normative.
>>
>>>  So we may need to find a reference to define that term.
>>>
>>
>>  Because the uses of the term are descriptive=20
>> and mostly background, I do not think we need=20
>> to add a definition or even a reference to a=20
>> definition of the term.
>>
>>  --Randall
>>
>>>
>>>  If Gunnar's suggested definition can be=20
>>> confirmed, this might be as simple as adding=20
>>> a reference to the IANA language tag=20
>>> repository.
>>>
>>>  On Sun, Nov 19, 2017 at 3:52 PM, Randall=20
>>> Gellens=20
>>> <rg+ietf@randy.pensive.org>=20
>>> wrote:
>>>
>>>  My view of issue #43 remains that we do not=20
>>> need to specify a mechanism for determining=20
>>> which tags are signed. In the email=20
>>> discussion of the past month or so, I fear we=20
>>> are drifting into adding complexity rather=20
>>> than removing it. I think the way forward is=20
>>> to keep this document as simple as possible.=20
>>> As Bernard notes in his email of 10/23, there=20
>>> is no benefit in this case of explicitly=20
>>> saying that certain things are not defined.=20
>>> Since the document does not define them, they=20
>>> are undefined in the document.
>>>
>>>  At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>
>>>  In other words,it is not clear to me how=20
>>> Section 5.4's discussion of scope improves or=20
>>> clarifies the situation in any way - and=20
>>> there is some possibility that it could cause=20
>>> problems.
>>>
>>>
>>>
>>>  I believe comment #43 should be closed as no=20
>>> longer applicable, since the text against=20
>>> which it was generated has been deleted.=20
>>> (I've said this before, and I believe it=20
>>> remains the case.)
>>>
>>>  The comment from which #43 derives was made=20
>>> against a version of the document that had=20
>>> text explicitly discussing signed versus=20
>>> unsigned tags. That text was subsequently=20
>>> deleted.
>>>
>>>  Here is the comment from which #43 derived:
>>>
>>>  5.2. New 'humintlang-send' and 'humintlang-recv' attributes
>>>
>>>  Note that while signed language tags are used with a video stream
>>>  to
>>>  indicate sign language, a spoken language tag for a video stream
>>>  in
>>>  parallel with an audio stream with the same spoken language tag
>>>  indicates a request for a supplemental video stream to see the
>>>  speaker.
>>>
>>>  And there's a similar paragraph in 5.4:
>>>
>>>  A spoken language tag for a video stream in conjunction with an
>>>
>>>  audio
>>>
>>>  stream with the same language might indicate a request for
>>>  supplemental video to see the speaker.
>>>
>>>
>>>  I think this mechanism needs to be described more exactly, and in
>>>  particular, it should not depend on the UA understanding which
>>>  language tags are spoken language tags. It seems to me that a
>>>  workable rule is that there is an audio stream and a video stream and
>>>  they specify exactly the same language tag in their respective
>>>  humintlang attributes. In that case, it is a request for a spoken
>>>  language with simultaneous video of the speaker, and those requests
>>>  should be considered satisfied only if both streams can be
>>>  established.
>>>
>>>
>>>  The offending text that was in 5.2 and 5.4 was deleted.
>>>
>>>  The only remaining text that even mentions the issue is Section 5.4:
>>>
>>>  The behavior when specifying a non-signed language tag for a video
>>>  media stream, or a signed language tag for an audio or text media
>>>  stream, is not defined in this document.
>>>
>>>  The problem of knowing which language tags are signed and which are
>>>  not is out of scope of this document.
>>>
>>>  So, let's delete Section 5.4 and be done with=20
>>> it. Neither of the statements is necessary.
>>>
>>>  --
>>>  Randall Gellens
>>>  Opinions are personal; facts are suspect; I speak for myself only
>>>  -------------- Randomly selected tag: ---------------
>>>  Make it right before you make it faster.
>>>
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
As far as the laws of mathematics refer to reality, they are not
certain; and as far as they are certain, they do not refer to reality.
                                                    --Albert Einstein


From nobody Mon Nov 20 10:41:36 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 AFBF912704B for ; Mon, 20 Nov 2017 10:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GhPuhFA6XtCw for ; Mon, 20 Nov 2017 10:41:31 -0800 (PST)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 048BB12706D for ; Mon, 20 Nov 2017 10:41:27 -0800 (PST)
Received: by mail-ua0-x22b.google.com with SMTP id 108so6573793uaf.2 for ; Mon, 20 Nov 2017 10:41:27 -0800 (PST)
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=IXASU4FwabK9yr+sr5imaO6sUM4cKh+kFwFrhRWS4ac=; b=s1205gNV/ZivKGem7rq2AHCWlOrHAR8tZR07AvzdFGeH7+WWPiPsYZi5dlvrtalSro sEFVTKbN3ralD0RynX1e5f0zKx1ahsY6E5IjWSxfuYsMhaaRW2r2+j53g41gXtCQU4C2 N3pyE07CeT8vdgbPsWt16h4Ntt1HJSP4HSo73KB63AGMc7NIMsSS5eLr6W81dpe+yb/e G9/7Rolzda7CbYWdsZRJq9TSBwZzHg2Sr5keBxcGurznnNcnwvZEhRJWeLewEFcjA5U7 o6NriiFtJgTFZpTsUTEf5YGWHcp4eGD3WV6Cb8zYjnD6KaDmVv8Ijs84tDDLpVQT3D1I Fhqg==
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=IXASU4FwabK9yr+sr5imaO6sUM4cKh+kFwFrhRWS4ac=; b=afyn7YL504beC3rsasb6w9/P6YXkwXCFsVS+x6Rd9zEXETszGrahGnkPf+NiST8lGu SFg2OclKaZE7AkkQP/PRD6//d/1JkhY7MREewzlmaMpYyK+H9+W6ael47EsrI+LLjoMi 5xBnI2cNlvBXBUnu9lxfviCaBuqeyDWU49eLAMFg0lv54AiFVp81WYmxOFJfTseJ3hZK 7bSejKEJAVISrn92uafGqcBBOoAqPlu5+uuGk3XyWP4j0RAkI8PbO4C6tA2HhCgSry4M jyBoS/Tfy1DleIzBWf3s+9ImlpPi4dedTgXPxRHHVzzml9Qdv5y5grOEk1aGDQA0Jm9D RiHQ==
X-Gm-Message-State: AJaThX51MovnO6rZs+riEZtSGNhM2wT/nRaI54c4x15q0E0kFMfL4YJ2 Ao23s4zDjcEJPdzoHhhlEFHrUHJaOM0n8NOnNSsy2EGY
X-Google-Smtp-Source: AGs4zMafDZlxTQNXr6Oaor9hbUTlOas41j0m5NpD/Y6vQQ7w5e+cuQ9YyvTYhZuChbOc5ysE4slhVAuu3MAWYe6uDSw=
X-Received: by 10.159.44.130 with SMTP id w2mr6992938uaj.202.1511203286716; Mon, 20 Nov 2017 10:41:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Mon, 20 Nov 2017 10:41:06 -0800 (PST)
In-Reply-To: <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
From: Bernard Aboba 
Date: Mon, 20 Nov 2017 10:41:06 -0800
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Cc: Randall Gellens , slim@ietf.org
Content-Type: multipart/alternative; boundary="089e082558b8169d7a055e6e6fc0"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 18:41:35 -0000

--089e082558b8169d7a055e6e6fc0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Gunnar said:

"5.4 Media, Language and Modality indications

The combination of Language tags and other information in the media
descriptions should be composed so that the intended modality can be
concluded by the negotiating parties. "

[BA] Is the "should" intended to be normative?

The following combinations of language tags and media provide obvious
information about the modality: sign language tags in video media indicate
signed modality... A sign language can be identified by the existence in
the IANA registry of language subtags according to BCP 47 [RFC5646] of the
language subtag with the Type field "extlang" combined with the Prefix
field value "sgn".  A specific spoken or written language can be identified
by not having any such "sgn" Prefix.

Use of language may appear in other media, such as "message" and
"application". Video media may be used for other modalities than signed.
Such use may be supported by further work or application specific
agreements or indications for evaluation of the intended modality. "

[BA] Assume we can confirm the mechanism for distinguishing
signed/non-signed languages, this part seems relatively solid.

spoken language tags for audio media indicate spoken modality and written
language tags for text media indicate written modality. The examples in
this specification are all from this set of three obvious
language/media/modality combinations.

[BA]  This is where the ground gets less solid - we don't really have a
general mechanism for distinguishing spoken and written modality among
non-signed languages. Perhaps we should just say "language tags in audio
media indicate spoken modality and language tags in text media indicate
written modality".





On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

> It is not the signed languages that are causing the problem. It is the
> spoken and written, when used in other media than the obvious audio and
> text media.
>
> And we should specify what is obvious and well defined and not, so here i=
s
> a new shorter proposal for section 5.4.
>
> -----Old text----
>
> 5.4 Undefined Combinations
>
>    The behavior when specifying a non-signed language tag for a video
>    media stream, or a signed language tag for an audio or text media
>    stream, is not defined in this document.
>
>    The problem of knowing which language tags are signed and which are
>    not is out of scope of this document.
>
> -----New text------------
> 5.4 Media, Language and Modality indications
>
> The combination of Language tags and other information in the media
> descriptions should be composed so that the intended modality can be
> concluded by the negotiating parties. The following combinations of
> language tags and media provide obvious information about the modality:
> sign language tags in video media indicate signed modality, spoken langua=
ge
> tags for audio media indicate spoken modality and written language tags f=
or
> text media indicate written modality. The examples in this specification
> are all from this set of three obvious language/media/modality combinatio=
ns.
>
> A sign language can be identified by the existence in the IANA registry o=
f
> language subtags according to BCP 47 [RFC5646] of the language subtag wit=
h
> the Type field "extlang" combined with the Prefix field value "sgn".
> A specific spoken or written language can be identified by not having any
> such "sgn" Prefix.
>
> Use of language may appear in other media, such as "message" and
> "application". Video media may be used for other modalities than signed.
> Such use may be supported by further work or application specific
> agreements or indications for evaluation of the intended modality.
>
> -------------------------------------------------------------------End of
> new text---------------------------------------
>
> Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>
> At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>
>  "So let's delete Section 5.4 and be done with it.  Neither of the
> statements is necessary."
>
>  [BA]  I agree that Section 5.4 does not add much value as it stands.
>
>  "Non-signed" is not used outside of Section 5.4, so there would not
> appear to be a need to define it if Section 5.4 were to be deleted.
>
>  However, the term "signed" is used in 7 other places in the document
> other than in Section 5.4.
>
>
> But none of those instances are normative.
>
>  So we may need to find a reference to define that term.
>
>
> Because the uses of the term are descriptive and mostly background, I do
> not think we need to add a definition or even a reference to a definition
> of the term.
>
> --Randall
>
>
>  If Gunnar's suggested definition can be confirmed,  this might be as
> simple as adding a reference to the IANA language tag repository.
>
>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens < pensive.org> rg+ietf@randy.pensive.org> wrote:
>
>  My view of issue #43 remains that we do not need to specify a mechanism
> for determining which tags are signed.  In the email discussion of the pa=
st
> month or so, I fear we are drifting into adding complexity rather than
> removing it.  I think the way forward is to keep this document as simple =
as
> possible.  As Bernard notes in his email of 10/23, there is no benefit in
> this case of explicitly saying that certain things are not defined.  Sinc=
e
> the document does not define them, they are undefined in the document.
>
>  At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>
>   In other words,it is not clear to me how Section 5.4's discussion of
> scope improves or clarifies the situation in any way - and there is some
> possibility that it could cause problems.
>
>
>
>  I believe comment #43 should be closed as no longer applicable, since th=
e
> text against which it was generated has been deleted. (I've said this
> before, and I believe it remains the case.)
>
>  The comment from which #43 derives was made against a version of the
> document that had text explicitly discussing signed versus unsigned tags.
> That text was subsequently deleted.
>
>  Here is the comment from which #43 derived:
>
>      5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>      Note that while signed language tags are used with a video stream
>   to
>      indicate sign language, a spoken language tag for a video stream
>   in
>      parallel with an audio stream with the same spoken language tag
>      indicates a request for a supplemental video stream to see the
>      speaker.
>
>   And there's a similar paragraph in 5.4:
>
>      A spoken language tag for a video stream in conjunction with an
>
>   audio
>
>      stream with the same language might indicate a request for
>      supplemental video to see the speaker.
>
>
>   I think this mechanism needs to be described more exactly, and in
>   particular, it should not depend on the UA understanding which
>   language tags are spoken language tags.  It seems to me that a
>   workable rule is that there is an audio stream and a video stream and
>   they specify exactly the same language tag in their respective
>   humintlang attributes.  In that case, it is a request for a spoken
>   language with simultaneous video of the speaker, and those requests
>   should be considered satisfied only if both streams can be
>   established.
>
>
>  The offending text that was in 5.2 and 5.4 was deleted.
>
>  The only remaining text that even mentions the issue is Section 5.4:
>
>     The behavior when specifying a non-signed language tag for a video
>     media stream, or a signed language tag for an audio or text media
>     stream, is not defined in this document.
>
>     The problem of knowing which language tags are signed and which are
>     not is out of scope of this document.
>
>  So, let's delete Section 5.4 and be done with it.  Neither of the
> statements is necessary.
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly selected tag: ---------------
>  Make it right before you make it faster.
>
>
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>

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


Gunnar said:=C2=A0

"5.4 Media, Language and Modality indications
The combin=
ation of Language tags and other information in the media descriptions shou=
ld be composed so that the intended modality can be concluded by the negoti=
ating parties. "

[BA] Is the "should"=
; intended to be normative?=C2=A0

The followi=
ng combinations of language tags and media provide obvious information abou=
t the modality: sign language tags in video media indicate signed modality.=
..=C2=A0A sign language can be iden=
tified by the existence in the IANA registry of language subtags according =
to BCP 47 [RFC5646] of the language subtag with the Type field "extlan=
g" combined with the Prefix field value "sgn".=C2=A0=C2=A0A specific spoken or written language=
 can be identified by not having any such "sgn" Prefix.

Use of language may appear in other media, such as &q=
uot;message" and "application". Video media may be used for =
other modalities than signed. Such use may be supported by further work or =
application specific agreements or indications for evaluation of the intend=
ed modality.=C2=A0"

[BA] Assume=
 we can confirm the mechanism for distinguishing signed/non-signed language=
s, this part seems relatively solid.=C2=A0

sp=
oken language tags for audio media indicate spoken modality and written lan=
guage tags for text media indicate written modality. The examples in this s=
pecification are all from this set of three obvious language/media/modality=
 combinations.

[BA]=C2=A0 This is where the=
 ground gets less solid - we don't really have a general mechanism for =
distinguishing spoken and written modality among non-signed languages. Perh=
aps we should just say "language tags in audio media indicate spoken m=
odality and language tags in text media indicate written modality".=C2=
=A0





On Mon, Nov 20, 2017 at 9:25 AM, =
Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

 =20
   =20
 =20
  

    
It is not the signed languages that are causing the problem. It
      is the spoken and written, when used in other media than the
      obvious audio and text media. 

    

    
And we should specify what is obvious and well defined and not,
      so here is a new shorter proposal for section 5.4.

    
-----Old text----

    
5.4 Undefined Combinations

   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


    -----New text------------

    5.4 Media, Language and Modality indications

    

    The combination of Language tags and other information in the media
    descriptions should be composed so that the intended modality can be
    concluded by the negotiating parties. The following combinations of
    language tags and media provide obvious information about the
    modality: sign language tags in video media indicate signed
    modality, spoken language tags for audio media indicate spoken
    modality and written language tags for text media indicate written
    modality. The examples in this specification are all from this set
    of three obvious language/media/modality combinations.

    

    A sign language can be identified by the existence in the IANA
    registry of language subtags according to BCP 47 [RFC5646] of the
    language subtag with the Type field "extlang" combined with t=
he
    Prefix field value "sgn". 

    A specific spoken or written language can be identified by not
    having any such "sgn" Prefix.

    

    Use of language may appear in other media, such as "message" =
and
    "application". Video media may be used for other modalities t=
han
    signed. Such use may be supported by further work or application
    specific agreements or indications for evaluation of the intended
    modality. 

    

-----------------------------------------------------------------=
--End
    of new text---------------------------------------


    
Den 2017-11-20 kl. =
15:55, skrev Randall
      Gellens:

    

    
At 7:47 PM -0800
      11/19/17, Bernard Aboba wrote:
      

      

      
=C2=A0"So let's delete Section 5.4=
 and be done
        with it.=C2=A0 Neither of the statements is necessary."
        

        

        =C2=A0[BA]=C2=A0 I agree that Section 5.4 does not add much value a=
s it
        stands.
        

        

        =C2=A0"Non-signed" is not used outside of Section 5.4, so=
 there would
        not appear to be a need to define it if Section 5.4 were to be
        deleted.
        

        

        =C2=A0However, the term "signed" is used in 7 other place=
s in the
        document other than in Section 5.4.
        

      

      

      But none of those instances are normative.
      

      

      
=C2=A0So we may need to find a reference to
        define that term.
        

      

      

      Because the uses of the term are descriptive and mostly
      background, I do not think we need to add a definition or even a
      reference to a definition of the term.
      

      

      --Randall
      

      

      

        

        =C2=A0If Gunnar's suggested definition can be confirmed,=C2=A0 =
this might
        be as simple as adding a reference to the IANA language tag
        repository.
        

        

        =C2=A0On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
<<mailto:rg+ietf@randy.=
pensive.org>rg+ietf@rand=
y.pensive.org>
        wrote:
        

        

        =C2=A0My view of issue #43 remains that we do not need to specify a
        mechanism for determining which tags are signed.=C2=A0 In the email
        discussion of the past month or so, I fear we are drifting into
        adding complexity rather than removing it.=C2=A0 I think the way
        forward is to keep this document as simple as possible.=C2=A0 As
        Bernard notes in his email of 10/23, there is no benefit in this
        case of explicitly saying that certain things are not defined.=C2=
=A0
        Since the document does not define them, they are undefined in
        the document.
        

        

        =C2=A0At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
        

        

        =C2=A0 In other words,it is not clear to me how Section 5.4's
        discussion of scope improves or clarifies the situation in any
        way - and there is some possibility that it could cause
        problems.
        

        

        

        

        =C2=A0I believe comment #43 should be closed as no longer applicabl=
e,
        since the text against which it was generated has been deleted.
        (I've said this before, and I believe it remains the case.)
        

        

        =C2=A0The comment from which #43 derives was made against a version
        of the document that had text explicitly discussing signed
        versus unsigned tags.=C2=A0 That text was subsequently deleted.
        

        

        =C2=A0Here is the comment from which #43 derived:
        

        

        =C2=A0=C2=A0=C2=A0=C2=A0 5.2.=C2=A0 New 'humintlang-send' a=
nd 'humintlang-recv'
        attributes
        

        

        =C2=A0=C2=A0=C2=A0=C2=A0 Note that while signed language tags are u=
sed with a video
        stream
        

        =C2=A0 to
        

        =C2=A0=C2=A0=C2=A0=C2=A0 indicate sign language, a spoken language =
tag for a video
        stream
        

        =C2=A0 in
        

        =C2=A0=C2=A0=C2=A0=C2=A0 parallel with an audio stream with the sam=
e spoken language
        tag
        

        =C2=A0=C2=A0=C2=A0=C2=A0 indicates a request for a supplemental vid=
eo stream to see
        the
        

        =C2=A0=C2=A0=C2=A0=C2=A0 speaker.
        

        

        =C2=A0 And there's a similar paragraph in 5.4:
        

        

        =C2=A0=C2=A0=C2=A0=C2=A0 A spoken language tag for a video stream i=
n conjunction
        with an
        

        

        =C2=A0 audio
        

        

        =C2=A0=C2=A0=C2=A0=C2=A0 stream with the same language might indica=
te a request for
        

        =C2=A0=C2=A0=C2=A0=C2=A0 supplemental video to see the speaker.
        

        

        

        =C2=A0 I think this mechanism needs to be described more exactly, a=
nd
        in
        

        =C2=A0 particular, it should not depend on the UA understanding whi=
ch
        

        =C2=A0 language tags are spoken language tags.=C2=A0 It seems to me=
 that a
        

        =C2=A0 workable rule is that there is an audio stream and a video
        stream and
        

        =C2=A0 they specify exactly the same language tag in their respecti=
ve
        

        =C2=A0 humintlang attributes.=C2=A0 In that case, it is a request f=
or a
        spoken
        

        =C2=A0 language with simultaneous video of the speaker, and those
        requests
        

        =C2=A0 should be considered satisfied only if both streams can be
        

        =C2=A0 established.
        

        

        

        =C2=A0The offending text that was in 5.2 and 5.4 was deleted.
        

        

        =C2=A0The only remaining text that even mentions the issue is Secti=
on
        5.4:
        

        

        =C2=A0=C2=A0=C2=A0 The behavior when specifying a non-signed langua=
ge tag for a
        video
        

        =C2=A0=C2=A0=C2=A0 media stream, or a signed language tag for an au=
dio or text
        media
        

        =C2=A0=C2=A0=C2=A0 stream, is not defined in this document.
        

        

        =C2=A0=C2=A0=C2=A0 The problem of knowing which language tags are s=
igned and
        which are
        

        =C2=A0=C2=A0=C2=A0 not is out of scope of this document.
        

        

        =C2=A0So, let's delete Section 5.4 and be done with it.=C2=A0 N=
either of
        the statements is necessary.
        

        

        =C2=A0--
        

        =C2=A0Randall Gellens
        

        =C2=A0Opinions are personal;=C2=A0=C2=A0=C2=A0 facts are suspect;=
=C2=A0=C2=A0=C2=A0 I speak for
        myself only
        

        =C2=A0-------------- Randomly selected tag: ---------------
        

        =C2=A0Make it right before you make it faster.
        

      

      

      

    

    

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

  






--089e082558b8169d7a055e6e6fc0--


From nobody Mon Nov 20 10:53: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 F1E3612E872 for ; Mon, 20 Nov 2017 10:53:49 -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, FREEMAIL_FROM=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=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a45fsgRcllnO for ; Mon, 20 Nov 2017 10:53:48 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D203B12E870 for ; Mon, 20 Nov 2017 10:53:48 -0800 (PST)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id GrBkeRivWpy9YGrCWeeMTL; Mon, 20 Nov 2017 18:53:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1511204028; bh=8emPSY6y+6zGejw6s/iS5pzP6etpHfxo++GJNltPDK8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=g+TRnANckRxa6oHrZb7KCtQa10dQSLzhN8ef1V0aqT04ze7FM2oJjtx2y3XPhVMKh eFRBSqUSmVdP+e0Wu6QHIoMaHQ5/tWjMtieFFo9WaCWAw4W3Qi2g14wscjjo2qunGw BPAjZUP4IHAsq8vhqms7fAXq/HzhZCSPRlJXLgoc1dK2bsU+GsMu0v9C0w3APDeEjO T9BoRkeLwDchV5GL3IvoovWzF8Wp5IgxML6ze+qwDjRoKTZ54Zk4UrstHdkhO1JXKJ qqmrSwp2VGz3gM2ltRkFwpe1cWmhvFWB1U72iN0UirF1/H09XjoEmW0C3xi2WBNxyT 1yILKQOkcIWGg==
Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-19v.sys.comcast.net with SMTP id GrCVerWkT5Ls1GrCVepFKT; Mon, 20 Nov 2017 18:53:47 +0000
To: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> 
From: Paul Kyzivat 
Message-ID: <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>
Date: Mon, 20 Nov 2017 13:53:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfLE1EVKeuloBh19+Bdmf3/3K7hOBP/3bWesEVMDQH0Ge4mUO3EJrWX99Y2MZrGKQxmk8p4wCLfL8ZfUasYdTa9UgCUnwY4k7Iovn6pGVdEDgFFtmql26 QZgDq5Pv4XiZEkbCtJa4GPhBjAQEn7DqcMenzys7Qodncs/MIhPpwUOHy16rvtY8+dyIUa5VZPZDnQ==
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 18:53:50 -0000

On 11/20/17 1:41 PM, Bernard Aboba wrote:

> [BA]  This is where the ground gets less solid - we don't really have a 
> general mechanism for distinguishing spoken and written modality among 
> non-signed languages. Perhaps we should just say "language tags in audio 
> media indicate spoken modality and language tags in text media indicate 
> written modality".

ISTM the real problem is with language tags in video media. These could 
indicate that the lip motions of people in the video reflect speakers of 
the tagged language. Or they could indicate written text in the 
specified language is embedded in the video. (Could be closed caption 
text or just signage.) Or (in the case of signed language tags) it could 
indicate use of sign language in the video.

But in the end, if this is declarative about what is being sent then it 
isn't clear whether it is important. If it is an indication of what is 
being requested, then it is more important.

	Thanks,
	Paul


From nobody Mon Nov 20 11:10:40 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 CFD7612EA52 for ; Mon, 20 Nov 2017 11:10:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tquE2J8w6SP1 for ; Mon, 20 Nov 2017 11:10:37 -0800 (PST)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEB512EA42 for ; Mon, 20 Nov 2017 11:10:36 -0800 (PST)
Received: by mail-ua0-x232.google.com with SMTP id q18so6631131uaa.0 for ; Mon, 20 Nov 2017 11:10:36 -0800 (PST)
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=LXFDNGajlfyfHt3whZtqMyfoTkHR3pxldLqF1CeeFcA=; b=BhZpsKts+Ae/RJtzM3rCcO6Z/96ZztnoTPRxNvoQHvixZmDb2WXJi/+P5t5LOBKf4H 2Ec8O6K4ZNhcP/qFnzJae3nVT+4DYcNxLXOT78kr2eO5o/14sOyoRFI6xdYbNVRtYX/Y Alyh/QcpnJEna9UjP+bHfqCOKEHJn4FYE005n68t5VMetcxm7Htsz9Mz4pjMo0zDAaGN 2cBwrtVjeEmnyeiyXTFameSfXOsXKxo9A4ukc7LKEhp5gW9tXltv/J8KznY41gBL7Mev 4f0a/cMHc2MSpaCcjYUq2zLFuK2FPCqFVFBd4Idcoa+SZO7f9MQUx/2CVrCJPd8Cv29v 0vjQ==
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=LXFDNGajlfyfHt3whZtqMyfoTkHR3pxldLqF1CeeFcA=; b=JS6ZXUaWX57e5nA5DPp2XGm0jiRbp51YNklhoCUJWVx6kvcFjr/R9d71/gP8Ja6j29 yXOMIqnsNF7mrLpBcRbiUO58LXncYSwoUy3hL1I0LKB0j/i4FoZ1yw8zsV9+Wv0eEfkI bdHLP9Cf0fGb9Xcsu8/OkPJfe/f0nL7/I8/gJtqVNphcgu2qnKnz6xgLF3sT1iskzHrT 2R6A+fqe4a78j47hkNrr6Z01wdSnUFk78HU1lXcCHB2B1mgs+IKPbesh9WnDpe2exgJg wrcjNPsPLYkGyTJ+pVw9lD/OSyTpL6Qt2+vnQIBx/hl1t0sfXRJ+teL3C8MpPpbUFquq krIw==
X-Gm-Message-State: AJaThX5xnFIgUPwGUjXWzt5wBAZ6jOxH19dI/+6vVFw0FUDBve0OhF3r dGJKuD6kb8YADccyyN9cLaG02yU91s7aetiyTkY=
X-Google-Smtp-Source: AGs4zMbIsBsMZJfCRDqsrcqPRF6tVZpLQ459KHpZDFkkSWHL33OyzejVzyC6D/s2HIEaayBSt5aIwtoSnw8okLnl6NI=
X-Received: by 10.176.71.226 with SMTP id w34mr13745113uac.33.1511205035585; Mon, 20 Nov 2017 11:10:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Mon, 20 Nov 2017 11:10:15 -0800 (PST)
In-Reply-To: <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>
From: Bernard Aboba 
Date: Mon, 20 Nov 2017 11:10:15 -0800
Message-ID: 
To: Paul Kyzivat 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="f4030437919854395a055e6ed7d8"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 19:10:39 -0000

--f4030437919854395a055e6ed7d8
Content-Type: text/plain; charset="UTF-8"

Paul said:

"ISTM the real problem is with language tags in video media. These could
indicate that the lip motions of people in the video reflect speakers of
the tagged language. Or they could indicate written text in the specified
language is embedded in the video. (Could be closed caption text or just
signage.) Or (in the case of signed language tags) it could indicate use of
sign language in the video.

But in the end, if this is declarative about what is being sent then it
isn't clear whether it is important. If it is an indication of what is
being requested, then it is more important."

[BA] Yes, that is the core of the problem.  As has been noted earlier, the
modality isn't indicated explicitly. I'm not sure whether we have enough
experience to know whether this represents an important deficit.  But we
could indicate that the problem potentially exists and that further work
might be needed.

On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat 
wrote:

> On 11/20/17 1:41 PM, Bernard Aboba wrote:
>
> [BA]  This is where the ground gets less solid - we don't really have a
>> general mechanism for distinguishing spoken and written modality among
>> non-signed languages. Perhaps we should just say "language tags in audio
>> media indicate spoken modality and language tags in text media indicate
>> written modality".
>>
>
> ISTM the real problem is with language tags in video media. These could
> indicate that the lip motions of people in the video reflect speakers of
> the tagged language. Or they could indicate written text in the specified
> language is embedded in the video. (Could be closed caption text or just
> signage.) Or (in the case of signed language tags) it could indicate use of
> sign language in the video.
>
> But in the end, if this is declarative about what is being sent then it
> isn't clear whether it is important. If it is an indication of what is
> being requested, then it is more important.
>
>         Thanks,
>         Paul
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


Paul said:=C2=A0

"ISTM the real problem is with language tags in video media=
. These could indicate that the lip motions of people in the video reflect =
speakers of the tagged language. Or they could indicate written text in the=
 specified language is embedded in the video. (Could be closed caption text=
 or just signage.) Or (in the case of signed language tags) it could indica=
te use of sign language in the video.

But in the end, if this is decl=
arative about what is being sent then it isn't clear whether it is impo=
rtant. If it is an indication of what is being requested, then it is more i=
mportant."

[BA] Yes, that is the core =
of the problem.=C2=A0 As has been noted earlier, the modality isn't ind=
icated explicitly. I'm not sure whether we have enough experience to kn=
ow whether this represents an important deficit.=C2=A0 But we could indicat=
e that the problem potentially exists and that further work might be needed=
.

On M=
on, Nov 20, 2017 at 10:53 AM, Paul Kyzivat <paul.kyzivat@comcast.ne=
t> wrote:
=
On 11/20/17 1:41 PM, Bernard Aboba wrote:





[BA]=C2=A0 This is where the ground gets less solid - we don't really h=
ave a general mechanism for distinguishing spoken and written modality amon=
g non-signed languages. Perhaps we should just say "language tags in a=
udio media indicate spoken modality and language tags in text media indicat=
e written modality".





ISTM the real problem is with language tags in video media. These could ind=
icate that the lip motions of people in the video reflect speakers of the t=
agged language. Or they could indicate written text in the specified langua=
ge is embedded in the video. (Could be closed caption text or just signage.=
) Or (in the case of signed language tags) it could indicate use of sign la=
nguage in the video.



But in the end, if this is declarative about what is being sent then it isn=
't clear whether it is important. If it is an indication of what is bei=
ng requested, then it is more important.



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

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



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--f4030437919854395a055e6ed7d8--


From nobody Mon Nov 20 11:20: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 6368612EA42 for ; Mon, 20 Nov 2017 11:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv7wI8MESiuV for ; Mon, 20 Nov 2017 11:20:03 -0800 (PST)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921CE12E957 for ; Mon, 20 Nov 2017 11:20:03 -0800 (PST)
Received: by mail-yb0-x235.google.com with SMTP id d59so3461393ybi.7 for ; Mon, 20 Nov 2017 11:20:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o3o+gOgoEAeUOF17ZVqda2itFFCN7YcnQlhNlniWMwg=; b=Nt6Mm4jAj1fBrV0HvfMQuEkqX00L3RS4ZcMn/6c2rAUcpdaoEyf6x1OYWm5Wkb2zbe CBdfLEyB5GHb/6t+ytIA5Js2xmWLvfF9bjUdnzPpZznUgX2h1IdKIQsfDauf7KEXxy9t LErrwF0We5gpbdw6JqkTZdQw4VHGBTlzdFHV/wIXumsNvHL3VQyb5/ZJXaDgdn0ZSwe0 urtNhALI6s1CagScODQIpYUNfDbEYo6Ry3KMxVzJcucbmVtEQNycI3vdP2uHOmLM+n25 25MqO9q38u51cHaio0ANMPvt0sXXso9fhZYemjiribqQUipMpYkV9CBSmhpo3TmqpCmH gcIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o3o+gOgoEAeUOF17ZVqda2itFFCN7YcnQlhNlniWMwg=; b=fJ5d64J0iAaaxK/nHsJ6ORu5sH0FTnA4mrip73CEoe/m1M6pzIskIK4orsNbpLznrf GSeX79tjJ6COF8hFEii0z46B5kdhJ3BWn9ffviaQGmFrHFmgcXP2QgeE9w43tg4chmUo rErAnss2KPfHMXu95vg6wWmjMrbNicHbGveyOOCS7I33p+g9TJeDOdrzKj5g22vPfyjK MnHKaBy8g0PxsrsF5VJ9ZfeHhZnALPWYw8bGfwOx1QFWc92wRHW07ZWeocen4CXRB4Xr pu9czo/7Wu4R5FeODMfmxo8/ZRDi6Ci9AKsD8rXMvJIDJ0nNy6vChPPfinavyhvm1aTC POuQ==
X-Gm-Message-State: AJaThX70B5uGG6CpDQ4zzxjcNYnq0wVCJNOgiKDXs7gwm6JuhMZsVknk ICaW01brAJ/Wgne+1pxAjbotXg==
X-Google-Smtp-Source: AGs4zMbyReGCXxwN/sqrsnidMRlk8DFBeAKpyjB68MmRv+4rVAq98soyQMd1m1txAVMXMMBk5ri33w==
X-Received: by 10.37.139.133 with SMTP id j5mr9277673ybl.4.1511205602624; Mon, 20 Nov 2017 11:20:02 -0800 (PST)
Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id n187sm4901076ywd.89.2017.11.20.11.20.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 11:20:01 -0800 (PST)
From: Brian Rosen 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FDF83877-1275-46EA-9ADF-B8DB41478AB8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 20 Nov 2017 14:19:59 -0500
In-Reply-To: 
Cc: Paul Kyzivat , slim@ietf.org
To: Bernard Aboba 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 19:20:08 -0000

--Apple-Mail=_FDF83877-1275-46EA-9ADF-B8DB41478AB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We=E2=80=99re not chartered to solve a problem like =E2=80=9Cwhat kind =
of information is in a video: lip motion, sign language, captions?=E2=80=9D=

I think when you signal a sign language in a language tag, we all know =
what to expect.  If you put anything else in a video stream, we don=E2=80=99=
t know what to expect, and this working group isn=E2=80=99t chartered to =
fix that.

So, say that, and only that: =E2=80=9CUse of a language selection in a =
video stream could have several meanings, including the use of sign =
language and visible captions.  If a sign language is signaled in a =
video stream, it is interpreted as the indicated sign language will =
appear in the video .  This document does not define any other use for =
language tags in video media.=E2=80=9D


> On Nov 20, 2017, at 2:10 PM, Bernard Aboba  =
wrote:
>=20
> Paul said:=20
>=20
> "ISTM the real problem is with language tags in video media. These =
could indicate that the lip motions of people in the video reflect =
speakers of the tagged language. Or they could indicate written text in =
the specified language is embedded in the video. (Could be closed =
caption text or just signage.) Or (in the case of signed language tags) =
it could indicate use of sign language in the video.
>=20
> But in the end, if this is declarative about what is being sent then =
it isn't clear whether it is important. If it is an indication of what =
is being requested, then it is more important."
>=20
> [BA] Yes, that is the core of the problem.  As has been noted earlier, =
the modality isn't indicated explicitly. I'm not sure whether we have =
enough experience to know whether this represents an important deficit.  =
But we could indicate that the problem potentially exists and that =
further work might be needed.
>=20
> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat =
> wrote:
> On 11/20/17 1:41 PM, Bernard Aboba wrote:
>=20
> [BA]  This is where the ground gets less solid - we don't really have =
a general mechanism for distinguishing spoken and written modality among =
non-signed languages. Perhaps we should just say "language tags in audio =
media indicate spoken modality and language tags in text media indicate =
written modality".
>=20
> ISTM the real problem is with language tags in video media. These =
could indicate that the lip motions of people in the video reflect =
speakers of the tagged language. Or they could indicate written text in =
the specified language is embedded in the video. (Could be closed =
caption text or just signage.) Or (in the case of signed language tags) =
it could indicate use of sign language in the video.
>=20
> But in the end, if this is declarative about what is being sent then =
it isn't clear whether it is important. If it is an indication of what =
is being requested, then it is more important.
>=20
>         Thanks,
>         Paul
>=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=_FDF83877-1275-46EA-9ADF-B8DB41478AB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

We=E2=80=99re not chartered to solve a problem like =E2=80=9Cwh=
at kind of information is in a video: lip motion, sign language, =
captions?=E2=80=9D
I think when you signal a sign =
language in a language tag, we all know what to expect.  If you put =
anything else in a video stream, we don=E2=80=99t know what to expect, =
and this working group isn=E2=80=99t chartered to fix that.

So, say that, and only =
that: =E2=80=9CUse of a language selection in a video stream could have =
several meanings, including the use of sign language and visible =
captions.  If a sign language is signaled in a video stream, it is =
interpreted as the indicated sign language will appear in the video . =
 This document does not define any other use for language tags in =
video media.=E2=80=9D


On Nov 20, 2017, at 2:10 PM, Bernard Aboba =
<bernard.aboba@gmail.com> wrote:

Paul said: 

"ISTM the real =
problem is with language tags in video media. These could indicate that =
the lip motions of people in the video reflect speakers of the tagged =
language. Or they could indicate written text in the specified language =
is embedded in the video. (Could be closed caption text or just =
signage.) Or (in the case of signed language tags) it could indicate use =
of sign language in the video.

But=
 in the end, if this is declarative about what is being sent then it =
isn't clear whether it is important. If it is an indication of what is =
being requested, then it is more important."

[BA] Yes, that is the =
core of the problem.  As has been noted earlier, the modality isn't =
indicated explicitly. I'm not sure whether we have enough experience to =
know whether this represents an important deficit.  But we could =
indicate that the problem potentially exists and that further work might =
be needed.

On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat =
<paul.kyzivat@comcast.net> wrote:
On =
11/20/17 1:41 PM, Bernard Aboba wrote:





[BA]  This is where the ground gets less solid - we don't really =
have a general mechanism for distinguishing spoken and written modality =
among non-signed languages. Perhaps we should just say "language tags in =
audio media indicate spoken modality and language tags in text media =
indicate written modality".





ISTM the real problem is with language tags in video media. These could =
indicate that the lip motions of people in the video reflect speakers of =
the tagged language. Or they could indicate written text in the =
specified language is embedded in the video. (Could be closed caption =
text or just signage.) Or (in the case of signed language tags) it could =
indicate use of sign language in the video.



But in the end, if this is declarative about what is being sent then it =
isn't clear whether it is important. If it is an indication of what is =
being requested, then it is more important.



        Thanks,

        Paul




_______________________________________________

SLIM mailing list

SLIM@ietf.org

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




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

=

--Apple-Mail=_FDF83877-1275-46EA-9ADF-B8DB41478AB8--


From nobody Mon Nov 20 12:04: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 4C8BA12EA95 for ; Mon, 20 Nov 2017 12:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 t87RBRy66Q64 for ; Mon, 20 Nov 2017 12:04:48 -0800 (PST)
Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B8129BCC for ; Mon, 20 Nov 2017 12:04:48 -0800 (PST)
X-AuditID: 12074414-0d3ff70000006ddf-1a-5a13355d7db0
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 29.8C.28127.D55331A5; Mon, 20 Nov 2017 15:04:45 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vAKK4iaK006420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Nov 2017 15:04:45 -0500
To: Bernard Aboba 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> 
From: Paul Kyzivat 
Message-ID: <48a8764f-ebf3-0e62-eb1a-390347d41263@alum.mit.edu>
Date: Mon, 20 Nov 2017 15:04:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixO6iqBtvKhxlMNHeYsO+/8wWMz90sjkw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGZ9/PWUq2ClecXXtSeYGxneCXYycHBICJhIT 189k7mLk4hAS2MEkcXPXE3YI5yGTxJo9y1lBqoQFgiQuTn3GBmKLCGhL9H3bxwRiMwsISuzp vAdmCwncY5Z4MoEfxGYT0JKYc+g/C4jNK2AvMelLH1gvi4CqRPPR08wgtqhAmsSdGQ+ZIGoE JU7OfAJWzykQKLFv1Xl2iPlmEvM2P2SGsMUlbj2ZD7VXXqJ562zmCYwCs5C0z0LSMgtJyywk LQsYWVYxyiXmlObq5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5ihASwyA7GIyflDjEKcDAq 8fB+4BGKEmJNLCuuzD3EKMnBpCTKu+o3UIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr1oUUI43 JbGyKrUoHyYlzcGiJM77bbG6n5BAemJJanZqakFqEUxWhoNDSYL3ibFwlJBgUWp6akVaZk4J QpqJgxNkOA/Q8OsgNbzFBYm5xZnpEPlTjK4cPT03/jBxPLpxF0hu+P4ASD6b+bqBmWPe8W9N zEIsefl5qVLivK+MgJoFQJozSvPg5sMS1StGcaB3hXnfg6zgASY5uA2vgJYzAS13ucAPsrwk ESEl1cDY9KYpzTh4tfFWy7+rdZodsmNlV7qKHuG6f87pwuwrs+SSBIofe7sz117WX5OzxXyf qltlhP3NTMGlzuWudrOapv7/cuWxqcbC9sNfb/+7yVi0sOzlE1/rdR5rsiyOzenh8Vz7Pifp wWr7M3zpv3geH57CtqRhwaaLGSm+S9Sy5L9xnTkndaBYiaU4I9FQi7moOBEAhrHm4S8DAAA=
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 20:04:50 -0000

On 11/20/17 2:10 PM, Bernard Aboba wrote:
> Paul said:
> 
> "ISTM the real problem is with language tags in video media. These could 
> indicate that the lip motions of people in the video reflect speakers of 
> the tagged language. Or they could indicate written text in the 
> specified language is embedded in the video. (Could be closed caption 
> text or just signage.) Or (in the case of signed language tags) it could 
> indicate use of sign language in the video.
> 
> But in the end, if this is declarative about what is being sent then it 
> isn't clear whether it is important. If it is an indication of what is 
> being requested, then it is more important."
> 
> [BA] Yes, that is the core of the problem.  As has been noted earlier, 
> the modality isn't indicated explicitly. I'm not sure whether we have 
> enough experience to know whether this represents an important deficit.  
> But we could indicate that the problem potentially exists and that 
> further work might be needed.

Of these, I think we can declare the lip sync "modality" to be a 
non-issue. There is already a way to signal lip sync in SDP. If that is 
used, then the language tag on the audio can be inferred to apply as 
well to the linked video. That wouldn't cover a case where you can see 
moving lips but there is no corresponding audio, but that doesn't seem 
like a very important case to address.

I'd be happy to just leave it marked as for future work.

	Thanks,
	Paul

> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat  > wrote:
> 
>     On 11/20/17 1:41 PM, Bernard Aboba wrote:
> 
>         [BA]  This is where the ground gets less solid - we don't really
>         have a general mechanism for distinguishing spoken and written
>         modality among non-signed languages. Perhaps we should just say
>         "language tags in audio media indicate spoken modality and
>         language tags in text media indicate written modality".
> 
> 
>     ISTM the real problem is with language tags in video media. These
>     could indicate that the lip motions of people in the video reflect
>     speakers of the tagged language. Or they could indicate written text
>     in the specified language is embedded in the video. (Could be closed
>     caption text or just signage.) Or (in the case of signed language
>     tags) it could indicate use of sign language in the video.
> 
>     But in the end, if this is declarative about what is being sent then
>     it isn't clear whether it is important. If it is an indication of
>     what is being requested, then it is more important.
> 
>              Thanks,
>              Paul
> 
> 
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>     
> 
> 


From nobody Mon Nov 20 12:44: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 BAF2F12EAB0 for ; Mon, 20 Nov 2017 12:44:55 -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 o7QlQFO8Abr3 for ; Mon, 20 Nov 2017 12:44:53 -0800 (PST)
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 8C36E120713 for ; Mon, 20 Nov 2017 12:44:52 -0800 (PST)
X-Halon-ID: a1484f3b-ce33-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id a1484f3b-ce33-11e7-96ae-005056917f90; Mon, 20 Nov 2017 21:44:41 +0100 (CET)
To: Bernard Aboba 
Cc: Randall Gellens , slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>
Date: Mon, 20 Nov 2017 21:44:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------366656AF2CC4538E771AA89C"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 20:44:56 -0000

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

Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
> Gunnar said:
>
> "5.4 Media, Language and Modality indications
>
> The combination of Language tags and other information in the media 
> descriptions should be composed so that the intended modality can be 
> concluded by the negotiating parties. "
>
> [BA] Is the "should" intended to be normative?
You are right that SHOULD should be avoided and it would be better 
to say MUST if we can. But I can imagine limited area applications 
having application agreements e.g. saying that a non-signed language tag 
in video media means a view of a talking person.   The negotiating 
applications know about this agreement so they can make the conclusion. 
So, if such situations can be included in how the parties make their 
conclusions, we can change to MUST.
>
> The following combinations of language tags and media provide obvious 
> information about the modality: sign language tags in video media 
> indicate signed modality... A sign language can be identified by the 
> existence in the IANA registry of language subtags according to BCP 47 
> [RFC5646] of the language subtag with the Type field "extlang" 
> combined with the Prefix field value "sgn". A specific spoken or 
> written language can be identified by not having any such "sgn" Prefix.
>
> Use of language may appear in other media, such as "message" and 
> "application". Video media may be used for other modalities than 
> signed. Such use may be supported by further work or application 
> specific agreements or indications for evaluation of the intended 
> modality."
>
> [BA] Assume we can confirm the mechanism for distinguishing 
> signed/non-signed languages, this part seems relatively solid.
>
> spoken language tags for audio media indicate spoken modality and 
> written language tags for text media indicate written modality. The 
> examples in this specification are all from this set of three obvious 
> language/media/modality combinations.
>
> [BA]  This is where the ground gets less solid - we don't really have 
> a general mechanism for distinguishing spoken and written modality 
> among non-signed languages. Perhaps we should just say "language tags 
> in audio media indicate spoken modality and language tags in text 
> media indicate written modality".
Yes, right, that is better wording.

Gunnar
>
>
>
>
>
> On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström 
> > wrote:
>
>     It is not the signed languages that are causing the problem. It is
>     the spoken and written, when used in other media than the obvious
>     audio and text media.
>
>     And we should specify what is obvious and well defined and not, so
>     here is a new shorter proposal for section 5.4.
>
>     -----Old text----
>
>
>           5.4 Undefined Combinations
>
>     The behavior when specifying a non-signed language tag for a video
>     media stream, or a signed language tag for an audio or text media
>     stream, is not defined in this document. The problem of knowing
>     which language tags are signed and which are not is out of scope
>     of this document.
>
>     -----New text------------
>     5.4 Media, Language and Modality indications
>
>     The combination of Language tags and other information in the
>     media descriptions should be composed so that the intended
>     modality can be concluded by the negotiating parties. The
>     following combinations of language tags and media provide obvious
>     information about the modality: sign language tags in video media
>     indicate signed modality, spoken language tags for audio media
>     indicate spoken modality and written language tags for text media
>     indicate written modality. The examples in this specification are
>     all from this set of three obvious language/media/modality
>     combinations.
>
>     A sign language can be identified by the existence in the IANA
>     registry of language subtags according to BCP 47 [RFC5646] of the
>     language subtag with the Type field "extlang" combined with the
>     Prefix field value "sgn".
>     A specific spoken or written language can be identified by not
>     having any such "sgn" Prefix.
>
>     Use of language may appear in other media, such as "message" and
>     "application". Video media may be used for other modalities than
>     signed. Such use may be supported by further work or application
>     specific agreements or indications for evaluation of the intended
>     modality.
>
>     -------------------------------------------------------------------End
>     of new text---------------------------------------
>
>     Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>     At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>
>>>      "So let's delete Section 5.4 and be done with it.  Neither of
>>>     the statements is necessary."
>>>
>>>      [BA]  I agree that Section 5.4 does not add much value as it
>>>     stands.
>>>
>>>      "Non-signed" is not used outside of Section 5.4, so there would
>>>     not appear to be a need to define it if Section 5.4 were to be
>>>     deleted.
>>>
>>>      However, the term "signed" is used in 7 other places in the
>>>     document other than in Section 5.4.
>>
>>     But none of those instances are normative.
>>
>>>      So we may need to find a reference to define that term.
>>
>>     Because the uses of the term are descriptive and mostly
>>     background, I do not think we need to add a definition or even a
>>     reference to a definition of the term.
>>
>>     --Randall
>>
>>>
>>>      If Gunnar's suggested definition can be confirmed,  this might
>>>     be as simple as adding a reference to the IANA language tag
>>>     repository.
>>>
>>>      On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
>>>     <
>>>     rg+ietf@randy.pensive.org
>>>     > wrote:
>>>
>>>      My view of issue #43 remains that we do not need to specify a
>>>     mechanism for determining which tags are signed.  In the email
>>>     discussion of the past month or so, I fear we are drifting into
>>>     adding complexity rather than removing it.  I think the way
>>>     forward is to keep this document as simple as possible.  As
>>>     Bernard notes in his email of 10/23, there is no benefit in this
>>>     case of explicitly saying that certain things are not defined. 
>>>     Since the document does not define them, they are undefined in
>>>     the document.
>>>
>>>      At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>
>>>       In other words,it is not clear to me how Section 5.4's
>>>     discussion of scope improves or clarifies the situation in any
>>>     way - and there is some possibility that it could cause problems.
>>>
>>>
>>>
>>>      I believe comment #43 should be closed as no longer applicable,
>>>     since the text against which it was generated has been deleted.
>>>     (I've said this before, and I believe it remains the case.)
>>>
>>>      The comment from which #43 derives was made against a version
>>>     of the document that had text explicitly discussing signed
>>>     versus unsigned tags.  That text was subsequently deleted.
>>>
>>>      Here is the comment from which #43 derived:
>>>
>>>          5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>>
>>>          Note that while signed language tags are used with a video
>>>     stream
>>>       to
>>>          indicate sign language, a spoken language tag for a video
>>>     stream
>>>       in
>>>          parallel with an audio stream with the same spoken language
>>>     tag
>>>          indicates a request for a supplemental video stream to see the
>>>          speaker.
>>>
>>>       And there's a similar paragraph in 5.4:
>>>
>>>          A spoken language tag for a video stream in conjunction
>>>     with an
>>>
>>>       audio
>>>
>>>          stream with the same language might indicate a request for
>>>          supplemental video to see the speaker.
>>>
>>>
>>>       I think this mechanism needs to be described more exactly, and in
>>>       particular, it should not depend on the UA understanding which
>>>       language tags are spoken language tags.  It seems to me that a
>>>       workable rule is that there is an audio stream and a video
>>>     stream and
>>>       they specify exactly the same language tag in their respective
>>>       humintlang attributes.  In that case, it is a request for a
>>>     spoken
>>>       language with simultaneous video of the speaker, and those
>>>     requests
>>>       should be considered satisfied only if both streams can be
>>>       established.
>>>
>>>
>>>      The offending text that was in 5.2 and 5.4 was deleted.
>>>
>>>      The only remaining text that even mentions the issue is Section
>>>     5.4:
>>>
>>>         The behavior when specifying a non-signed language tag for a
>>>     video
>>>         media stream, or a signed language tag for an audio or text
>>>     media
>>>         stream, is not defined in this document.
>>>
>>>         The problem of knowing which language tags are signed and
>>>     which are
>>>         not is out of scope of this document.
>>>
>>>      So, let's delete Section 5.4 and be done with it.  Neither of
>>>     the statements is necessary.
>>>
>>>      --
>>>      Randall Gellens
>>>      Opinions are personal;    facts are suspect;    I speak for
>>>     myself only
>>>      -------------- Randomly selected tag: ---------------
>>>      Make it right before you make it faster.
>>
>>
>
>     -- ----------------------------------------- Gunnar Hellström
>     Omnitor gunnar.hellstrom@omnitor.se
>      +46 708 204 288
>
>

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


--------------366656AF2CC4538E771AA89C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:

    

      
Gunnar said: 
        


        

        
"5.4 Media, Language and
            Modality indications

        

        The combination of Language tags
          and other information in the media descriptions should be
          composed so that the intended modality can be concluded by the
          negotiating parties. "
        


          

        
[BA] Is the "should"
            intended to be normative? 

          

      

    

    <GH>You are right that SHOULD should be avoided and it would
    be better to say MUST if we can. But I can imagine limited area
    applications having application agreements e.g. saying that a
    non-signed language tag in video media means a view of a talking
    person.   The negotiating applications know about this agreement so
    they can make the conclusion. So, if such situations can be included
    in how the parties make their conclusions, we can change to MUST.  

    

      

        


          

        
The following combinations
            of language tags and media provide obvious information about
            the modality: sign language tags in video media indicate
            signed modality... A
            sign language can be identified by the existence in the IANA
            registry of language subtags according to BCP 47 [RFC5646]
            of the language subtag with the Type field "extlang"
            combined with the Prefix field value "sgn".  A specific spoken or written
            language can be identified by not having any such "sgn"
            Prefix.

        


          

        
Use of language may appear
            in other media, such as "message" and "application". Video
            media may be used for other modalities than signed. Such use
            may be supported by further work or application specific
            agreements or indications for evaluation of the intended
            modality. "

          

        


          

        
[BA] Assume we can confirm
            the mechanism for distinguishing signed/non-signed
            languages, this part seems relatively solid. 

        


          

        
spoken language tags for
            audio media indicate spoken modality and written language
            tags for text media indicate written modality. The examples
            in this specification are all from this set of three obvious
            language/media/modality combinations.

        


        

        
[BA]  This is where the ground gets less solid - we don't
          really have a general mechanism for distinguishing spoken and
          written modality among non-signed languages. Perhaps we should
          just say "language tags in audio media indicate spoken
          modality and language tags in text media indicate written
          modality". 

        

      

    

    Yes, right, that is better wording.

    

    Gunnar

    

      

        


          

          

          


          

        

      

      


        
On Mon, Nov 20, 2017 at 9:25 AM, Gunnar
          Hellström <gunnar.hellstrom@omnitor.se>
          wrote:

          

            

              
It is not the signed languages that are causing the
                problem. It is the spoken and written, when used in
                other media than the obvious audio and text media. 

              

              
And we should specify what is obvious and well defined
                and not, so here is a new shorter proposal for section
                5.4.

              
-----Old text----

              
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


              -----New text------------

              5.4 Media, Language and Modality indications

              

              The combination of Language tags and other information in
              the media descriptions should be composed so that the
              intended modality can be concluded by the negotiating
              parties. The following combinations of language tags and
              media provide obvious information about the modality: sign
              language tags in video media indicate signed modality,
              spoken language tags for audio media indicate spoken
              modality and written language tags for text media indicate
              written modality. The examples in this specification are
              all from this set of three obvious language/media/modality
              combinations.

              

              A sign language can be identified by the existence in the
              IANA registry of language subtags according to BCP 47
              [RFC5646] of the language subtag with the Type field
              "extlang" combined with the Prefix field value "sgn". 

              A specific spoken or written language can be identified by
              not having any such "sgn" Prefix.

              

              Use of language may appear in other media, such as
              "message" and "application". Video media may be used for
              other modalities than signed. Such use may be supported by
              further work or application specific agreements or
              indications for evaluation of the intended modality. 

              

              -------------------------------------------------------------------End
              of new text---------------------------------------
              

                


                  
Den
                    2017-11-20 kl. 15:55, skrev Randall Gellens:

                  

                  
At 7:47 PM -0800 11/19/17,
                    Bernard Aboba wrote: 

                    

                    
 "So let's delete Section
                      5.4 and be done with it.  Neither of the
                      statements is necessary." 

                      

                       [BA]  I agree that Section 5.4 does not add much
                      value as it stands. 

                      

                       "Non-signed" is not used outside of Section 5.4,
                      so there would not appear to be a need to define
                      it if Section 5.4 were to be deleted. 

                      

                       However, the term "signed" is used in 7 other
                      places in the document other than in Section 5.4.
                      

                    

                    

                    But none of those instances are normative. 

                    

                    
 So we may need to find a
                      reference to define that term. 

                    

                    

                    Because the uses of the term are descriptive and
                    mostly background, I do not think we need to add a
                    definition or even a reference to a definition of
                    the term. 

                    

                    --Randall 

                    

                    
 

                       If Gunnar's suggested definition can be
                      confirmed,  this might be as simple as adding a
                      reference to the IANA language tag repository. 

                      

                       On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
                      <<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org>
                      wrote: 

                      

                       My view of issue #43 remains that we do not need
                      to specify a mechanism for determining which tags
                      are signed.  In the email discussion of the past
                      month or so, I fear we are drifting into adding
                      complexity rather than removing it.  I think the
                      way forward is to keep this document as simple as
                      possible.  As Bernard notes in his email of 10/23,
                      there is no benefit in this case of explicitly
                      saying that certain things are not defined.  Since
                      the document does not define them, they are
                      undefined in the document. 

                      

                       At 6:51 PM -0700 10/23/17, Bernard Aboba wrote: 

                      

                        In other words,it is not clear to me how Section
                      5.4's discussion of scope improves or clarifies
                      the situation in any way - and there is some
                      possibility that it could cause problems. 

                      

                      

                      

                       I believe comment #43 should be closed as no
                      longer applicable, since the text against which it
                      was generated has been deleted. (I've said this
                      before, and I believe it remains the case.) 

                      

                       The comment from which #43 derives was made
                      against a version of the document that had text
                      explicitly discussing signed versus unsigned
                      tags.  That text was subsequently deleted. 

                      

                       Here is the comment from which #43 derived: 

                      

                           5.2.  New 'humintlang-send' and
                      'humintlang-recv' attributes 

                      

                           Note that while signed language tags are used
                      with a video stream 

                        to 

                           indicate sign language, a spoken language tag
                      for a video stream 

                        in 

                           parallel with an audio stream with the same
                      spoken language tag 

                           indicates a request for a supplemental video
                      stream to see the 

                           speaker. 

                      

                        And there's a similar paragraph in 5.4: 

                      

                           A spoken language tag for a video stream in
                      conjunction with an 

                      

                        audio 

                      

                           stream with the same language might indicate
                      a request for 

                           supplemental video to see the speaker. 

                      

                      

                        I think this mechanism needs to be described
                      more exactly, and in 

                        particular, it should not depend on the UA
                      understanding which 

                        language tags are spoken language tags.  It
                      seems to me that a 

                        workable rule is that there is an audio stream
                      and a video stream and 

                        they specify exactly the same language tag in
                      their respective 

                        humintlang attributes.  In that case, it is a
                      request for a spoken 

                        language with simultaneous video of the speaker,
                      and those requests 

                        should be considered satisfied only if both
                      streams can be 

                        established. 

                      

                      

                       The offending text that was in 5.2 and 5.4 was
                      deleted. 

                      

                       The only remaining text that even mentions the
                      issue is Section 5.4: 

                      

                          The behavior when specifying a non-signed
                      language tag for a video 

                          media stream, or a signed language tag for an
                      audio or text media 

                          stream, is not defined in this document. 

                      

                          The problem of knowing which language tags are
                      signed and which are 

                          not is out of scope of this document. 

                      

                       So, let's delete Section 5.4 and be done with
                      it.  Neither of the statements is necessary. 

                      

                       -- 

                       Randall Gellens 

                       Opinions are personal;    facts are suspect;    I
                      speak for myself only 

                       -------------- Randomly selected tag:
                      --------------- 

                       Make it right before you make it faster. 

                    

                    

                    

                  

                  

                

              

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

            

          

        

        

      

    

    

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

  


--------------366656AF2CC4538E771AA89C--


From nobody Mon Nov 20 13:04:05 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 9A4E012EAAE for ; Mon, 20 Nov 2017 13:04:04 -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 9N4JF7C8qDlw for ; Mon, 20 Nov 2017 13:04:02 -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 3ECEC12E056 for ; Mon, 20 Nov 2017 13:04:02 -0800 (PST)
X-Halon-ID: 52fc410d-ce36-11e7-811c-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 52fc410d-ce36-11e7-811c-0050569116f7; Mon, 20 Nov 2017 22:03:58 +0100 (CET)
To: Paul Kyzivat , Bernard Aboba 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>  <48a8764f-ebf3-0e62-eb1a-390347d41263@alum.mit.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <3ad59ba4-4bc4-e174-e67e-c7fba70ca108@omnitor.se>
Date: Mon, 20 Nov 2017 22:03:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <48a8764f-ebf3-0e62-eb1a-390347d41263@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 21:04:04 -0000

Den 2017-11-20 kl. 21:04, skrev Paul Kyzivat:
> On 11/20/17 2:10 PM, Bernard Aboba wrote:
>> Paul said:
>>
>> "ISTM the real problem is with language tags in video media. These 
>> could indicate that the lip motions of people in the video reflect 
>> speakers of the tagged language. Or they could indicate written text 
>> in the specified language is embedded in the video. (Could be closed 
>> caption text or just signage.) Or (in the case of signed language 
>> tags) it could indicate use of sign language in the video.
>>
>> But in the end, if this is declarative about what is being sent then 
>> it isn't clear whether it is important. If it is an indication of 
>> what is being requested, then it is more important."
>>
>> [BA] Yes, that is the core of the problem.  As has been noted 
>> earlier, the modality isn't indicated explicitly. I'm not sure 
>> whether we have enough experience to know whether this represents an 
>> important deficit.  But we could indicate that the problem 
>> potentially exists and that further work might be needed.
>
> Of these, I think we can declare the lip sync "modality" to be a 
> non-issue. There is already a way to signal lip sync in SDP. If that 
> is used, then the language tag on the audio can be inferred to apply 
> as well to the linked video. That wouldn't cover a case where you can 
> see moving lips but there is no corresponding audio, but that doesn't 
> seem like a very important case to address.
>
> I'd be happy to just leave it marked as for future work.
Yes, further work, or application pre-agreement.

Gunnar
>
>     Thanks,
>     Paul
>
>> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat 
>> > wrote:
>>
>>     On 11/20/17 1:41 PM, Bernard Aboba wrote:
>>
>>         [BA]  This is where the ground gets less solid - we don't really
>>         have a general mechanism for distinguishing spoken and written
>>         modality among non-signed languages. Perhaps we should just say
>>         "language tags in audio media indicate spoken modality and
>>         language tags in text media indicate written modality".
>>
>>
>>     ISTM the real problem is with language tags in video media. These
>>     could indicate that the lip motions of people in the video reflect
>>     speakers of the tagged language. Or they could indicate written text
>>     in the specified language is embedded in the video. (Could be closed
>>     caption text or just signage.) Or (in the case of signed language
>>     tags) it could indicate use of sign language in the video.
>>
>>     But in the end, if this is declarative about what is being sent then
>>     it isn't clear whether it is important. If it is an indication of
>>     what is being requested, then it is more important.
>>
>>              Thanks,
>>              Paul
>>
>>
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>>     
>>
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Mon Nov 20 13:14:17 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 A5EB6128CD5 for ; Mon, 20 Nov 2017 13:14:15 -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 Uy9AbKMbCVkG for ; Mon, 20 Nov 2017 13:14:12 -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 111CE120713 for ; Mon, 20 Nov 2017 13:14:11 -0800 (PST)
X-Halon-ID: b7e98d10-ce37-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id b7e98d10-ce37-11e7-96ae-005056917f90; Mon, 20 Nov 2017 22:13:56 +0100 (CET)
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
To: Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>
Message-ID: 
Date: Mon, 20 Nov 2017 22:14:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>
Content-Type: multipart/alternative; boundary="------------D6A18448AEF52BA1A3CDD8B7"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 21:14:16 -0000

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

A new proposal for new text taking in latest discussion of Bernard, Paul 
and Brian:

-----Old text----


      5.4 Undefined Combinations

The behavior when specifying a non-signed language tag for a video media 
stream, or a signed language tag for an audio or text media stream, is 
not defined in this document. The problem of knowing which language tags 
are signed and which are not is out of scope of this document.

-----New text------------
5.4 Media, Language and Modality indications

The combination of Language tags and other information in the media 
descriptions shall be composed so that the intended modality can be 
concluded by the negotiating parties. The following combinations of 
language tags and media provide obvious information about the modality: 
sign language tags in video media indicate signed modality, language 
tags in audio media indicate spoken modality and language tags in text 
media indicate written modality. The examples in this specification are 
all from this set of three obvious language/media/modality combinations.

A sign language can be identified by the existence in the IANA registry 
of language subtags according to BCP 47 [RFC5646] of the language subtag 
with the Type field "extlang" combined with the Prefix field value "sgn".
A specific spoken or written language can be identified by not having 
any such "sgn" Prefix.

Use of language may appear in other media, such as "message" and 
"application". Video media may be used for other modalities than signed, 
e.g. a view of a speaker or text captions. Such use may be supported by 
further work or application specific agreements for evaluation of the 
intended modality.

---------------------------End of new 
text---------------------------------------


Den 2017-11-20 kl. 21:44, skrev Gunnar Hellström:
> Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>> Gunnar said:
>>
>> "5.4 Media, Language and Modality indications
>>
>> The combination of Language tags and other information in the media 
>> descriptions should be composed so that the intended modality can be 
>> concluded by the negotiating parties. "
>>
>> [BA] Is the "should" intended to be normative?
> You are right that SHOULD should be avoided and it would be better 
> to say MUST if we can. But I can imagine limited area applications 
> having application agreements e.g. saying that a non-signed language 
> tag in video media means a view of a talking person.   The negotiating 
> applications know about this agreement so they can make the 
> conclusion. So, if such situations can be included in how the parties 
> make their conclusions, we can change to MUST.
>>
>> The following combinations of language tags and media provide obvious 
>> information about the modality: sign language tags in video media 
>> indicate signed modality... A sign language can be identified by the 
>> existence in the IANA registry of language subtags according to BCP 
>> 47 [RFC5646] of the language subtag with the Type field "extlang" 
>> combined with the Prefix field value "sgn". A specific spoken or 
>> written language can be identified by not having any such "sgn" Prefix.
>>
>> Use of language may appear in other media, such as "message" and 
>> "application". Video media may be used for other modalities than 
>> signed. Such use may be supported by further work or application 
>> specific agreements or indications for evaluation of the intended 
>> modality."
>>
>> [BA] Assume we can confirm the mechanism for distinguishing 
>> signed/non-signed languages, this part seems relatively solid.
>>
>> spoken language tags for audio media indicate spoken modality and 
>> written language tags for text media indicate written modality. The 
>> examples in this specification are all from this set of three obvious 
>> language/media/modality combinations.
>>
>> [BA]  This is where the ground gets less solid - we don't really have 
>> a general mechanism for distinguishing spoken and written modality 
>> among non-signed languages. Perhaps we should just say "language tags 
>> in audio media indicate spoken modality and language tags in text 
>> media indicate written modality".
> Yes, right, that is better wording.
>
> Gunnar
>>
>>
>>
>>
>>
>> On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström 
>> > wrote:
>>
>>     It is not the signed languages that are causing the problem. It
>>     is the spoken and written, when used in other media than the
>>     obvious audio and text media.
>>
>>     And we should specify what is obvious and well defined and not,
>>     so here is a new shorter proposal for section 5.4.
>>
>>     -----Old text----
>>
>>
>>           5.4 Undefined Combinations
>>
>>     The behavior when specifying a non-signed language tag for a
>>     video media stream, or a signed language tag for an audio or text
>>     media stream, is not defined in this document. The problem of
>>     knowing which language tags are signed and which are not is out
>>     of scope of this document.
>>
>>     -----New text------------
>>     5.4 Media, Language and Modality indications
>>
>>     The combination of Language tags and other information in the
>>     media descriptions should be composed so that the intended
>>     modality can be concluded by the negotiating parties. The
>>     following combinations of language tags and media provide obvious
>>     information about the modality: sign language tags in video media
>>     indicate signed modality, spoken language tags for audio media
>>     indicate spoken modality and written language tags for text media
>>     indicate written modality. The examples in this specification are
>>     all from this set of three obvious language/media/modality
>>     combinations.
>>
>>     A sign language can be identified by the existence in the IANA
>>     registry of language subtags according to BCP 47 [RFC5646] of the
>>     language subtag with the Type field "extlang" combined with the
>>     Prefix field value "sgn".
>>     A specific spoken or written language can be identified by not
>>     having any such "sgn" Prefix.
>>
>>     Use of language may appear in other media, such as "message" and
>>     "application". Video media may be used for other modalities than
>>     signed. Such use may be supported by further work or application
>>     specific agreements or indications for evaluation of the intended
>>     modality.
>>
>>     -------------------------------------------------------------------End
>>     of new text---------------------------------------
>>
>>     Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>>     At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>
>>>>      "So let's delete Section 5.4 and be done with it.  Neither of
>>>>     the statements is necessary."
>>>>
>>>>      [BA]  I agree that Section 5.4 does not add much value as it
>>>>     stands.
>>>>
>>>>      "Non-signed" is not used outside of Section 5.4, so there
>>>>     would not appear to be a need to define it if Section 5.4 were
>>>>     to be deleted.
>>>>
>>>>      However, the term "signed" is used in 7 other places in the
>>>>     document other than in Section 5.4.
>>>
>>>     But none of those instances are normative.
>>>
>>>>      So we may need to find a reference to define that term.
>>>
>>>     Because the uses of the term are descriptive and mostly
>>>     background, I do not think we need to add a definition or even a
>>>     reference to a definition of the term.
>>>
>>>     --Randall
>>>
>>>>
>>>>      If Gunnar's suggested definition can be confirmed,  this might
>>>>     be as simple as adding a reference to the IANA language tag
>>>>     repository.
>>>>
>>>>      On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
>>>>     <
>>>>     rg+ietf@randy.pensive.org
>>>>     > wrote:
>>>>
>>>>      My view of issue #43 remains that we do not need to specify a
>>>>     mechanism for determining which tags are signed.  In the email
>>>>     discussion of the past month or so, I fear we are drifting into
>>>>     adding complexity rather than removing it. I think the way
>>>>     forward is to keep this document as simple as possible.  As
>>>>     Bernard notes in his email of 10/23, there is no benefit in
>>>>     this case of explicitly saying that certain things are not
>>>>     defined.  Since the document does not define them, they are
>>>>     undefined in the document.
>>>>
>>>>      At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>>
>>>>       In other words,it is not clear to me how Section 5.4's
>>>>     discussion of scope improves or clarifies the situation in any
>>>>     way - and there is some possibility that it could cause problems.
>>>>
>>>>
>>>>
>>>>      I believe comment #43 should be closed as no longer
>>>>     applicable, since the text against which it was generated has
>>>>     been deleted. (I've said this before, and I believe it remains
>>>>     the case.)
>>>>
>>>>      The comment from which #43 derives was made against a version
>>>>     of the document that had text explicitly discussing signed
>>>>     versus unsigned tags.  That text was subsequently deleted.
>>>>
>>>>      Here is the comment from which #43 derived:
>>>>
>>>>          5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>>>
>>>>          Note that while signed language tags are used with a video
>>>>     stream
>>>>       to
>>>>          indicate sign language, a spoken language tag for a video
>>>>     stream
>>>>       in
>>>>          parallel with an audio stream with the same spoken
>>>>     language tag
>>>>          indicates a request for a supplemental video stream to see
>>>>     the
>>>>          speaker.
>>>>
>>>>       And there's a similar paragraph in 5.4:
>>>>
>>>>          A spoken language tag for a video stream in conjunction
>>>>     with an
>>>>
>>>>       audio
>>>>
>>>>          stream with the same language might indicate a request for
>>>>          supplemental video to see the speaker.
>>>>
>>>>
>>>>       I think this mechanism needs to be described more exactly,
>>>>     and in
>>>>       particular, it should not depend on the UA understanding which
>>>>       language tags are spoken language tags.  It seems to me that a
>>>>       workable rule is that there is an audio stream and a video
>>>>     stream and
>>>>       they specify exactly the same language tag in their respective
>>>>       humintlang attributes.  In that case, it is a request for a
>>>>     spoken
>>>>       language with simultaneous video of the speaker, and those
>>>>     requests
>>>>       should be considered satisfied only if both streams can be
>>>>       established.
>>>>
>>>>
>>>>      The offending text that was in 5.2 and 5.4 was deleted.
>>>>
>>>>      The only remaining text that even mentions the issue is
>>>>     Section 5.4:
>>>>
>>>>         The behavior when specifying a non-signed language tag for
>>>>     a video
>>>>         media stream, or a signed language tag for an audio or text
>>>>     media
>>>>         stream, is not defined in this document.
>>>>
>>>>         The problem of knowing which language tags are signed and
>>>>     which are
>>>>         not is out of scope of this document.
>>>>
>>>>      So, let's delete Section 5.4 and be done with it.  Neither of
>>>>     the statements is necessary.
>>>>
>>>>      --
>>>>      Randall Gellens
>>>>      Opinions are personal;    facts are suspect; I speak for
>>>>     myself only
>>>>      -------------- Randomly selected tag: ---------------
>>>>      Make it right before you make it faster.
>>>
>>>
>>
>>     -- ----------------------------------------- Gunnar Hellström
>>     Omnitor gunnar.hellstrom@omnitor.se
>>      +46 708 204 288
>>
>>
>
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------D6A18448AEF52BA1A3CDD8B7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
A new proposal for new text taking in latest discussion of
      Bernard, Paul and Brian:

    
-----Old text----

    
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


    -----New text------------

    5.4 Media, Language and Modality indications

    

    The combination of Language tags and other information in the media
    descriptions shall be composed so that the intended modality can be
    concluded by the negotiating parties. The following combinations of
    language tags and media provide obvious information about the
    modality: sign language tags in video media indicate signed
    modality, language tags in audio media indicate spoken modality and
    language tags in text media indicate written modality. The examples
    in this specification are all from this set of three obvious
    language/media/modality combinations.

    

    A sign language can be identified by the existence in the IANA
    registry of language subtags according to BCP 47 [RFC5646] of the
    language subtag with the Type field "extlang" combined with the
    Prefix field value "sgn". 

    A specific spoken or written language can be identified by not
    having any such "sgn" Prefix.

    

    Use of language may appear in other media, such as "message" and
    "application". Video media may be used for other modalities than
    signed, e.g. a view of a speaker or text captions. Such use may be
    supported by further work or application specific agreements for
    evaluation of the intended modality. 

    

    ---------------------------End of new
    text---------------------------------------
    
 

    

    
Den 2017-11-20 kl. 21:44, skrev Gunnar
      Hellström:

    

    

      
      Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:

      

        
Gunnar said: 
          


          

          
"5.4 Media, Language and
              Modality indications

          

          The combination of Language
            tags and other information in the media descriptions should
            be composed so that the intended modality can be concluded
            by the negotiating parties. "
          


            

          
[BA] Is the "should"
              intended to be normative? 

            

        

      

      <GH>You are right that SHOULD should be avoided and it would
      be better to say MUST if we can. But I can imagine limited area
      applications having application agreements e.g. saying that a
      non-signed language tag in video media means a view of a talking
      person.   The negotiating applications know about this agreement
      so they can make the conclusion. So, if such situations can be
      included in how the parties make their conclusions, we can change
      to MUST.  

      

        

          


            

          
The following combinations
              of language tags and media provide obvious information
              about the modality: sign language tags in video media
              indicate signed modality... A sign language can be identified
              by the existence in the IANA registry of language subtags
              according to BCP 47 [RFC5646] of the language subtag with
              the Type field "extlang" combined with the Prefix field
              value "sgn".  A
              specific spoken or written language can be identified by
              not having any such "sgn" Prefix.

          


            

          
Use of language may appear
              in other media, such as "message" and "application". Video
              media may be used for other modalities than signed. Such
              use may be supported by further work or application
              specific agreements or indications for evaluation of the
              intended modality. "

            

          


            

          
[BA] Assume we can confirm
              the mechanism for distinguishing signed/non-signed
              languages, this part seems relatively solid. 

          


            

          
spoken language tags for
              audio media indicate spoken modality and written language
              tags for text media indicate written modality. The
              examples in this specification are all from this set of
              three obvious language/media/modality combinations.

          


          

          
[BA]  This is where the ground gets less solid - we don't
            really have a general mechanism for distinguishing spoken
            and written modality among non-signed languages. Perhaps we
            should just say "language tags in audio media indicate
            spoken modality and language tags in text media indicate
            written modality". 

          

        

      

      Yes, right, that is better wording.

      

      Gunnar

      

        

          


            

            

            


            

          

        

        


          
On Mon, Nov 20, 2017 at 9:25 AM,
            Gunnar Hellström <gunnar.hellstrom@omnitor.se>
            wrote:

            

              

                
It is not the signed languages that are causing the
                  problem. It is the spoken and written, when used in
                  other media than the obvious audio and text media. 

                

                
And we should specify what is obvious and well
                  defined and not, so here is a new shorter proposal for
                  section 5.4.

                
-----Old text----

                
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


                -----New text------------

                5.4 Media, Language and Modality indications

                

                The combination of Language tags and other information
                in the media descriptions should be composed so that the
                intended modality can be concluded by the negotiating
                parties. The following combinations of language tags and
                media provide obvious information about the modality:
                sign language tags in video media indicate signed
                modality, spoken language tags for audio media indicate
                spoken modality and written language tags for text media
                indicate written modality. The examples in this
                specification are all from this set of three obvious
                language/media/modality combinations.

                

                A sign language can be identified by the existence in
                the IANA registry of language subtags according to BCP
                47 [RFC5646] of the language subtag with the Type field
                "extlang" combined with the Prefix field value "sgn". 

                A specific spoken or written language can be identified
                by not having any such "sgn" Prefix.

                

                Use of language may appear in other media, such as
                "message" and "application". Video media may be used for
                other modalities than signed. Such use may be supported
                by further work or application specific agreements or
                indications for evaluation of the intended modality. 

                

                -------------------------------------------------------------------End
                of new text---------------------------------------
                

                  


                    
Den
                      2017-11-20 kl. 15:55, skrev Randall Gellens:

                    

                    
At 7:47 PM -0800 11/19/17,
                      Bernard Aboba wrote: 

                      

                      
 "So let's delete Section
                        5.4 and be done with it.  Neither of the
                        statements is necessary." 

                        

                         [BA]  I agree that Section 5.4 does not add
                        much value as it stands. 

                        

                         "Non-signed" is not used outside of Section
                        5.4, so there would not appear to be a need to
                        define it if Section 5.4 were to be deleted. 

                        

                         However, the term "signed" is used in 7 other
                        places in the document other than in Section
                        5.4. 

                      

                      

                      But none of those instances are normative. 

                      

                      
 So we may need to find a
                        reference to define that term. 

                      

                      

                      Because the uses of the term are descriptive and
                      mostly background, I do not think we need to add a
                      definition or even a reference to a definition of
                      the term. 

                      

                      --Randall 

                      

                      
 

                         If Gunnar's suggested definition can be
                        confirmed,  this might be as simple as adding a
                        reference to the IANA language tag repository. 

                        

                         On Sun, Nov 19, 2017 at 3:52 PM, Randall
                        Gellens <<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org>
                        wrote: 

                        

                         My view of issue #43 remains that we do not
                        need to specify a mechanism for determining
                        which tags are signed.  In the email discussion
                        of the past month or so, I fear we are drifting
                        into adding complexity rather than removing it. 
                        I think the way forward is to keep this document
                        as simple as possible.  As Bernard notes in his
                        email of 10/23, there is no benefit in this case
                        of explicitly saying that certain things are not
                        defined.  Since the document does not define
                        them, they are undefined in the document. 

                        

                         At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
                        

                        

                          In other words,it is not clear to me how
                        Section 5.4's discussion of scope improves or
                        clarifies the situation in any way - and there
                        is some possibility that it could cause
                        problems. 

                        

                        

                        

                         I believe comment #43 should be closed as no
                        longer applicable, since the text against which
                        it was generated has been deleted. (I've said
                        this before, and I believe it remains the case.)
                        

                        

                         The comment from which #43 derives was made
                        against a version of the document that had text
                        explicitly discussing signed versus unsigned
                        tags.  That text was subsequently deleted. 

                        

                         Here is the comment from which #43 derived: 

                        

                             5.2.  New 'humintlang-send' and
                        'humintlang-recv' attributes 

                        

                             Note that while signed language tags are
                        used with a video stream 

                          to 

                             indicate sign language, a spoken language
                        tag for a video stream 

                          in 

                             parallel with an audio stream with the same
                        spoken language tag 

                             indicates a request for a supplemental
                        video stream to see the 

                             speaker. 

                        

                          And there's a similar paragraph in 5.4: 

                        

                             A spoken language tag for a video stream in
                        conjunction with an 

                        

                          audio 

                        

                             stream with the same language might
                        indicate a request for 

                             supplemental video to see the speaker. 

                        

                        

                          I think this mechanism needs to be described
                        more exactly, and in 

                          particular, it should not depend on the UA
                        understanding which 

                          language tags are spoken language tags.  It
                        seems to me that a 

                          workable rule is that there is an audio stream
                        and a video stream and 

                          they specify exactly the same language tag in
                        their respective 

                          humintlang attributes.  In that case, it is a
                        request for a spoken 

                          language with simultaneous video of the
                        speaker, and those requests 

                          should be considered satisfied only if both
                        streams can be 

                          established. 

                        

                        

                         The offending text that was in 5.2 and 5.4 was
                        deleted. 

                        

                         The only remaining text that even mentions the
                        issue is Section 5.4: 

                        

                            The behavior when specifying a non-signed
                        language tag for a video 

                            media stream, or a signed language tag for
                        an audio or text media 

                            stream, is not defined in this document. 

                        

                            The problem of knowing which language tags
                        are signed and which are 

                            not is out of scope of this document. 

                        

                         So, let's delete Section 5.4 and be done with
                        it.  Neither of the statements is necessary. 

                        

                         -- 

                         Randall Gellens 

                         Opinions are personal;    facts are suspect;   
                        I speak for myself only 

                         -------------- Randomly selected tag:
                        --------------- 

                         Make it right before you make it faster. 

                      

                      

                      

                    

                    

                  

                

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

              

            

          

          

        

      

      

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

      

      

      

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


    

    

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

  


--------------D6A18448AEF52BA1A3CDD8B7--


From nobody Mon Nov 20 13:19:42 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 D906E12EAB3 for ; Mon, 20 Nov 2017 13:19:40 -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 dURCTEDM2Hz7 for ; Mon, 20 Nov 2017 13:19:38 -0800 (PST)
Received: from bin-vsp-out-01.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 B29E91270B4 for ; Mon, 20 Nov 2017 13:19:37 -0800 (PST)
X-Halon-ID: 7a400f24-ce38-11e7-aaf2-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [83.209.157.37]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 7a400f24-ce38-11e7-aaf2-005056917a89; Mon, 20 Nov 2017 22:19:23 +0100 (CET)
To: Brian Rosen 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <002bffe3-429d-f4c8-f965-d49fcc1ca590@omnitor.se>
Date: Mon, 20 Nov 2017 22:19:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CAAC9228B109328678EE0E06"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 21:19:41 -0000

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

Den 2017-11-20 kl. 20:19, skrev Brian Rosen:

> We’re not chartered to solve a problem like “what kind of information 
> is in a video: lip motion, sign language, captions?”
> I think when you signal a sign language in a language tag, we all know 
> what to expect.  If you put anything else in a video stream, we don’t 
> know what to expect, and this working group isn’t chartered to fix that.
>
> So, say that, and only that: “Use of a language selection in a video 
> stream could have several meanings, including the use of sign language 
> and visible captions.  If a sign language is signaled in a video 
> stream, it is interpreted as the indicated sign language will appear 
> in the video .  This document does not define any other use for 
> language tags in video media.”
Yes, except for "WILL appear". It may still be just an indication of 
preference or capability and not yet sure that it will appear.
Anyway, I hope you find the wording in my latest just submitted proposal 
also suitable.

Gunnar
>
>
>> On Nov 20, 2017, at 2:10 PM, Bernard Aboba > > wrote:
>>
>> Paul said:
>>
>> "ISTM the real problem is with language tags in video media. These 
>> could indicate that the lip motions of people in the video reflect 
>> speakers of the tagged language. Or they could indicate written text 
>> in the specified language is embedded in the video. (Could be closed 
>> caption text or just signage.) Or (in the case of signed language 
>> tags) it could indicate use of sign language in the video.
>>
>> But in the end, if this is declarative about what is being sent then 
>> it isn't clear whether it is important. If it is an indication of 
>> what is being requested, then it is more important."
>>
>> [BA] Yes, that is the core of the problem.  As has been noted 
>> earlier, the modality isn't indicated explicitly. I'm not sure 
>> whether we have enough experience to know whether this represents an 
>> important deficit.  But we could indicate that the problem 
>> potentially exists and that further work might be needed.
>>
>> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat 
>> > wrote:
>>
>>     On 11/20/17 1:41 PM, Bernard Aboba wrote:
>>
>>         [BA]  This is where the ground gets less solid - we don't
>>         really have a general mechanism for distinguishing spoken and
>>         written modality among non-signed languages. Perhaps we
>>         should just say "language tags in audio media indicate spoken
>>         modality and language tags in text media indicate written
>>         modality".
>>
>>
>>     ISTM the real problem is with language tags in video media. These
>>     could indicate that the lip motions of people in the video
>>     reflect speakers of the tagged language. Or they could indicate
>>     written text in the specified language is embedded in the video.
>>     (Could be closed caption text or just signage.) Or (in the case
>>     of signed language tags) it could indicate use of sign language
>>     in the video.
>>
>>     But in the end, if this is declarative about what is being sent
>>     then it isn't clear whether it is important. If it is an
>>     indication of what is being requested, then it is more important.
>>
>>             Thanks,
>>             Paul
>>
>>
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>>     
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org 
>> https://www.ietf.org/mailman/listinfo/slim
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------CAAC9228B109328678EE0E06
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Den 2017-11-20 kl. 20:19, skrev Brian Rosen:

    

    

      
      We’re not chartered to solve a problem like “what kind of
      information is in a video: lip motion, sign language, captions?”
      
I think when you signal a sign language in a
        language tag, we all know what to expect.  If you put anything
        else in a video stream, we don’t know what to expect, and this
        working group isn’t chartered to fix that.

      


      

      
So, say that, and only that: “Use of a language
        selection in a video stream could have several meanings,
        including the use of sign language and visible captions.  If a
        sign language is signaled in a video stream, it is interpreted
        as the indicated sign language will appear in the video .  This
        document does not define any other use for language tags in
        video media.”

    

    <GH>Yes, except for "WILL appear". It may still be just an
    indication of preference or capability and not yet sure that it will
    appear. 

    Anyway, I hope you find the wording in my latest just submitted
    proposal also suitable.

    

    Gunnar

    

      


      

      


        

          

            

              
On Nov 20, 2017, at 2:10 PM, Bernard Aboba
                <bernard.aboba@gmail.com>
                wrote:

              

              

                
Paul said: 
                  


                  

                  
"ISTM
                      the real problem is with language tags in video
                      media. These could indicate that the lip motions
                      of people in the video reflect speakers of the
                      tagged language. Or they could indicate written
                      text in the specified language is embedded in the
                      video. (Could be closed caption text or just
                      signage.) Or (in the case of signed language tags)
                      it could indicate use of sign language in the
                      video.

                  

                  
But
                      in the end, if this is declarative about what is
                      being sent then it isn't clear whether it is
                      important. If it is an indication of what is being
                      requested, then it is more important."

                  


                  

                  
[BA] Yes, that is the core of the
                    problem.  As has been noted earlier, the modality
                    isn't indicated explicitly. I'm not sure whether we
                    have enough experience to know whether this
                    represents an important deficit.  But we could
                    indicate that the problem potentially exists and
                    that further work might be needed.

                

                


                  
On Mon, Nov 20, 2017 at 10:53
                    AM, Paul Kyzivat <paul.kyzivat@comcast.net>
                    wrote:

                    
On 11/20/17 1:41 PM, Bernard Aboba
                        wrote:

                        

                        

                          [BA]  This is where the ground gets less solid
                          - we don't really have a general mechanism for
                          distinguishing spoken and written modality
                          among non-signed languages. Perhaps we should
                          just say "language tags in audio media
                          indicate spoken modality and language tags in
                          text media indicate written modality".

                        

                        

                      
                      ISTM the real problem is with language tags in
                      video media. These could indicate that the lip
                      motions of people in the video reflect speakers of
                      the tagged language. Or they could indicate
                      written text in the specified language is embedded
                      in the video. (Could be closed caption text or
                      just signage.) Or (in the case of signed language
                      tags) it could indicate use of sign language in
                      the video.

                      

                      But in the end, if this is declarative about what
                      is being sent then it isn't clear whether it is
                      important. If it is an indication of what is being
                      requested, then it is more important.

                      

                              Thanks,

                              Paul
                      

                        


                          

                          _______________________________________________

                          SLIM mailing list

                          SLIM@ietf.org

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

                        

                      

                    

                  

                  

                

                _______________________________________________

                SLIM mailing list

                SLIM@ietf.org

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

              

            

          

          

        

      

      

      

      

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


    

    

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

  


--------------CAAC9228B109328678EE0E06--


From nobody Mon Nov 20 14:17:25 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 937AE12EAA8 for ; Mon, 20 Nov 2017 14:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 x9oH1QytiFgW for ; Mon, 20 Nov 2017 14:17:20 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 6F45412704A for ; Mon, 20 Nov 2017 14:17:20 -0800 (PST)
Received: by mail-vk0-x233.google.com with SMTP id o145so6509571vkd.0 for ; Mon, 20 Nov 2017 14:17:20 -0800 (PST)
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=sqIXJh/AJa1gC5MG8RIsS81rpWqI8zdCUiXIRvGqqTU=; b=UI+MwUZIB681pcKp2zRcdV6bCeMj902dCUWbt2o6azgb4Fz6PB+jdeEoCZ9aKNaCPf nwUnlK9wq5xD/C89Yf3EnZNj8Dm3DZSVLfWZ5VfB0dSBOI2b8FVHcPnDpgfTeIPJUGHJ gxlicCD8zBl+dRrs7YLAh5hDJ1J8KyaX9K4r3GY0eQ3HZ71RXwetTTgr7NY5TBv/Ztkw drFLSdP/Oh7CxWr+powiV8B4YNtcGiH5Qxkaws3ERy8p9Why1D2aeIGywEpr2uwj4dnV YBjZCytrQOWd0xLsVowgotkIyKWI+9M1fG6iOGCrc8yAM3ame+9sBDhiXdMhm93/VEFp X85g==
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=sqIXJh/AJa1gC5MG8RIsS81rpWqI8zdCUiXIRvGqqTU=; b=aGkSOjS3j2pW66FeGgOM6GncJz6TEA12UTqsh9oLMj/OTcfqCO7TL51jsOk1Hwn8Mg NhcZpOPJpjtCsbjan3vZdFK5UZBbH263jV5R2YSuM35///5SwTV6e6VqOfS2l25Gw5ZG bzxQiQHrCq8ONB8W2R0lBPmk/hjw2nWLxFmOVleqCSPcs93x4btQeGi/bkRVPWryQ0Ml pstvsaAoo1yRRkv+z1I1dS3JtW0Mcu+xvBkamTgCi0X70gFW7mpEE6GkZqBSkuKP0BE7 XRNcXUa14KmgK7dAPB18TBmWP0yfRg7FZUk32yKWh5mv/Qpyo21sUPtrGyLnT2OQ/mF9 AW/A==
X-Gm-Message-State: AJaThX7d5GbbO2U908dfZJIvh0IXCm5rzhST3DF9ECS9lOFk9qHbvcA7 dSyncn6KdgY0OWtPixTSgWnMHkOeePDKqsoxMUY=
X-Google-Smtp-Source: AGs4zMb9wyvr+37x5ddKxU/+r4p6AN4tGNmIuGA07fTinpePWJ5Rm8Q2UMMMs8LXJLCU3JukU46+HkMfTfWtRe4toRQ=
X-Received: by 10.31.92.22 with SMTP id q22mr11428543vkb.10.1511216239111; Mon, 20 Nov 2017 14:17:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Mon, 20 Nov 2017 14:16:58 -0800 (PST)
In-Reply-To: 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> 
From: Bernard Aboba 
Date: Mon, 20 Nov 2017 14:16:58 -0800
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Cc: slim@ietf.org, Randall Gellens 
Content-Type: multipart/alternative; boundary="001a114e61a21c75f8055e71736a"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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: Mon, 20 Nov 2017 22:17:23 -0000

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

Can we include text from Brian's suggestion? For example:

"If a sign language is signaled in a video stream, it is interpreted as an
indication that sign language will appear in the video.  A sign language
can be identified by the existence in the IANA registry of language subtags
according to BCP 47 [RFC5646] of the language subtag with the Type field
"extlang" combined with the Prefix field value "sgn".  A spoken/written
language tag can be identified by not having any such "sgn" prefix. This
document does not define any other use for language tags in video media
(such as how to indicate a desire for visible captions).

This document does not define the use of sign language tags in text or
audio media.  If a spoken/written language tag is included in text media,
it indicates a desire for written language. If a spoken/written language
tag is included in audio media, it is interpreted as an indication that
spoken language is desired.  Using the "lip sync" grouping mechanism
defined in [RFC5888], it is possible to indicate the desire to synchronize
audio and video so as to support lip reading.

Use of language tags may appear in other media, such as "message" and
"application".  Such use may be supported by further work or application
specific agreement."



On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

> A new proposal for new text taking in latest discussion of Bernard, Paul
> and Brian:
>
> -----Old text----
>
> 5.4 Undefined Combinations
>
>    The behavior when specifying a non-signed language tag for a video
>    media stream, or a signed language tag for an audio or text media
>    stream, is not defined in this document.
>
>    The problem of knowing which language tags are signed and which are
>    not is out of scope of this document.
>
> -----New text------------
> 5.4 Media, Language and Modality indications
>
> The combination of Language tags and other information in the media
> descriptions shall be composed so that the intended modality can be
> concluded by the negotiating parties. The following combinations of
> language tags and media provide obvious information about the modality:
> sign language tags in video media indicate signed modality, language tags
> in audio media indicate spoken modality and language tags in text media
> indicate written modality. The examples in this specification are all fro=
m
> this set of three obvious language/media/modality combinations.
>
> A sign language can be identified by the existence in the IANA registry o=
f
> language subtags according to BCP 47 [RFC5646] of the language subtag wit=
h
> the Type field "extlang" combined with the Prefix field value "sgn".
> A specific spoken or written language can be identified by not having any
> such "sgn" Prefix.
>
> Use of language may appear in other media, such as "message" and
> "application". Video media may be used for other modalities than signed,
> e.g. a view of a speaker or text captions. Such use may be supported by
> further work or application specific agreements for evaluation of the
> intended modality.
>
> ---------------------------End of new text-------------------------------=
--------
>
>
>
> Den 2017-11-20 kl. 21:44, skrev Gunnar Hellstr=C3=B6m:
>
> Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>
> Gunnar said:
>
> "5.4 Media, Language and Modality indications
>
> The combination of Language tags and other information in the media
> descriptions should be composed so that the intended modality can be
> concluded by the negotiating parties. "
>
> [BA] Is the "should" intended to be normative?
>
> You are right that SHOULD should be avoided and it would be better to
> say MUST if we can. But I can imagine limited area applications having
> application agreements e.g. saying that a non-signed language tag in vide=
o
> media means a view of a talking person.   The negotiating applications kn=
ow
> about this agreement so they can make the conclusion. So, if such
> situations can be included in how the parties make their conclusions, we
> can change to MUST.
>
>
> The following combinations of language tags and media provide obvious
> information about the modality: sign language tags in video media indicat=
e
> signed modality... A sign language can be identified by the existence in
> the IANA registry of language subtags according to BCP 47 [RFC5646] of th=
e
> language subtag with the Type field "extlang" combined with the Prefix
> field value "sgn".  A specific spoken or written language can be
> identified by not having any such "sgn" Prefix.
>
> Use of language may appear in other media, such as "message" and
> "application". Video media may be used for other modalities than signed.
> Such use may be supported by further work or application specific
> agreements or indications for evaluation of the intended modality. "
>
> [BA] Assume we can confirm the mechanism for distinguishing
> signed/non-signed languages, this part seems relatively solid.
>
> spoken language tags for audio media indicate spoken modality and written
> language tags for text media indicate written modality. The examples in
> this specification are all from this set of three obvious
> language/media/modality combinations.
>
> [BA]  This is where the ground gets less solid - we don't really have a
> general mechanism for distinguishing spoken and written modality among
> non-signed languages. Perhaps we should just say "language tags in audio
> media indicate spoken modality and language tags in text media indicate
> written modality".
>
> Yes, right, that is better wording.
>
> Gunnar
>
>
>
>
>
>
> On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellstr=C3=B6m <
> gunnar.hellstrom@omnitor.se> wrote:
>
>> It is not the signed languages that are causing the problem. It is the
>> spoken and written, when used in other media than the obvious audio and
>> text media.
>>
>> And we should specify what is obvious and well defined and not, so here
>> is a new shorter proposal for section 5.4.
>>
>> -----Old text----
>>
>> 5.4 Undefined Combinations
>>
>>    The behavior when specifying a non-signed language tag for a video
>>    media stream, or a signed language tag for an audio or text media
>>    stream, is not defined in this document.
>>
>>    The problem of knowing which language tags are signed and which are
>>    not is out of scope of this document.
>>
>> -----New text------------
>> 5.4 Media, Language and Modality indications
>>
>> The combination of Language tags and other information in the media
>> descriptions should be composed so that the intended modality can be
>> concluded by the negotiating parties. The following combinations of
>> language tags and media provide obvious information about the modality:
>> sign language tags in video media indicate signed modality, spoken langu=
age
>> tags for audio media indicate spoken modality and written language tags =
for
>> text media indicate written modality. The examples in this specification
>> are all from this set of three obvious language/media/modality combinati=
ons.
>>
>> A sign language can be identified by the existence in the IANA registry
>> of language subtags according to BCP 47 [RFC5646] of the language subtag
>> with the Type field "extlang" combined with the Prefix field value "sgn"=
.
>> A specific spoken or written language can be identified by not having an=
y
>> such "sgn" Prefix.
>>
>> Use of language may appear in other media, such as "message" and
>> "application". Video media may be used for other modalities than signed.
>> Such use may be supported by further work or application specific
>> agreements or indications for evaluation of the intended modality.
>>
>> -------------------------------------------------------------------End
>> of new text---------------------------------------
>>
>> Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>
>> At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>
>>  "So let's delete Section 5.4 and be done with it.  Neither of the
>> statements is necessary."
>>
>>  [BA]  I agree that Section 5.4 does not add much value as it stands.
>>
>>  "Non-signed" is not used outside of Section 5.4, so there would not
>> appear to be a need to define it if Section 5.4 were to be deleted.
>>
>>  However, the term "signed" is used in 7 other places in the document
>> other than in Section 5.4.
>>
>>
>> But none of those instances are normative.
>>
>>  So we may need to find a reference to define that term.
>>
>>
>> Because the uses of the term are descriptive and mostly background, I do
>> not think we need to add a definition or even a reference to a definitio=
n
>> of the term.
>>
>> --Randall
>>
>>
>>  If Gunnar's suggested definition can be confirmed,  this might be as
>> simple as adding a reference to the IANA language tag repository.
>>
>>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens <
>>  
>> rg+ietf@randy.pensive.org> wrote:
>>
>>  My view of issue #43 remains that we do not need to specify a mechanism
>> for determining which tags are signed.  In the email discussion of the p=
ast
>> month or so, I fear we are drifting into adding complexity rather than
>> removing it.  I think the way forward is to keep this document as simple=
 as
>> possible.  As Bernard notes in his email of 10/23, there is no benefit i=
n
>> this case of explicitly saying that certain things are not defined.  Sin=
ce
>> the document does not define them, they are undefined in the document.
>>
>>  At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>
>>   In other words,it is not clear to me how Section 5.4's discussion of
>> scope improves or clarifies the situation in any way - and there is some
>> possibility that it could cause problems.
>>
>>
>>
>>  I believe comment #43 should be closed as no longer applicable, since
>> the text against which it was generated has been deleted. (I've said thi=
s
>> before, and I believe it remains the case.)
>>
>>  The comment from which #43 derives was made against a version of the
>> document that had text explicitly discussing signed versus unsigned tags=
.
>> That text was subsequently deleted.
>>
>>  Here is the comment from which #43 derived:
>>
>>      5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>
>>      Note that while signed language tags are used with a video stream
>>   to
>>      indicate sign language, a spoken language tag for a video stream
>>   in
>>      parallel with an audio stream with the same spoken language tag
>>      indicates a request for a supplemental video stream to see the
>>      speaker.
>>
>>   And there's a similar paragraph in 5.4:
>>
>>      A spoken language tag for a video stream in conjunction with an
>>
>>   audio
>>
>>      stream with the same language might indicate a request for
>>      supplemental video to see the speaker.
>>
>>
>>   I think this mechanism needs to be described more exactly, and in
>>   particular, it should not depend on the UA understanding which
>>   language tags are spoken language tags.  It seems to me that a
>>   workable rule is that there is an audio stream and a video stream and
>>   they specify exactly the same language tag in their respective
>>   humintlang attributes.  In that case, it is a request for a spoken
>>   language with simultaneous video of the speaker, and those requests
>>   should be considered satisfied only if both streams can be
>>   established.
>>
>>
>>  The offending text that was in 5.2 and 5.4 was deleted.
>>
>>  The only remaining text that even mentions the issue is Section 5.4:
>>
>>     The behavior when specifying a non-signed language tag for a video
>>     media stream, or a signed language tag for an audio or text media
>>     stream, is not defined in this document.
>>
>>     The problem of knowing which language tags are signed and which are
>>     not is out of scope of this document.
>>
>>  So, let's delete Section 5.4 and be done with it.  Neither of the
>> statements is necessary.
>>
>>  --
>>  Randall Gellens
>>  Opinions are personal;    facts are suspect;    I speak for myself only
>>  -------------- Randomly selected tag: ---------------
>>  Make it right before you make it faster.
>>
>>
>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitorgunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>

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


Can we include text from Brian's suggestion? For examp=
le:=C2=A0

"If a si=
gn language is signaled in a video stream, it is interpreted as an indicati=
on that sign language will appear in the video.=C2=A0=C2=A0A sign language can be identifie=
d by the existence in the IANA registry of language subtags according to BC=
P 47 [RFC5646] of the language subtag with the Type field "extlang&quo=
t; combined with the Prefix field value "sgn".=C2=A0=C2=A0A =
spoken/written language tag can be identified by not having any such "=
sgn" prefix.=C2=A0This document does not define any other use for=
 language tags in video media (such as how to indicate a desire for visible=
 captions).

This document does not define the=
 use of sign language tags in text or audio media.=C2=A0=C2=A0If a spoken/written language tag is included in =
text media, it indicates a desire for written language.=C2=A0If a spoken/written language tag is included in a=
udio media, it is interpreted as an indication that spoken language is desi=
red.=C2=A0 Using the "lip sync" grouping mechanism defined in [RF=
C5888], it is possible to indicate the desire to synchronize audio and vide=
o so as to support lip reading.

Use of language tags may appear in other media, such =
as "message" and "application".=C2=A0 Such use may be s=
upported by further work or application specific agreement."=C2=A0



On Mon, Nov 20, 2017 at 1:14 PM=
, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:

 =20
   =20
 =20
  

    
A new proposal for new text taking in latest discussion of
      Bernard, Paul and Brian:

    
-----Old text----

    
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


    -----New text------------

    5.4 Media, Language and Modality indications

    

    The combination of Language tags and other information in the media
    descriptions shall be composed so that the intended modality can be
    concluded by the negotiating parties. The following combinations of
    language tags and media provide obvious information about the
    modality: sign language tags in video media indicate signed
    modality, language tags in audio media indicate spoken modality and
    language tags in text media indicate written modality. The examples
    in this specification are all from this set of three obvious
    language/media/modality combinations.

    

    A sign language can be identified by the existence in the IANA
    registry of language subtags according to BCP 47 [RFC5646] of the
    language subtag with the Type field "extlang" combined with t=
he
    Prefix field value "sgn". 

    A specific spoken or written language can be identified by not
    having any such "sgn" Prefix.

    

    Use of language may appear in other media, such as "message" =
and
    "application". Video media may be used for other modalities t=
han
    signed, e.g. a view of a speaker or text captions. Such use may be
    supported by further work or application specific agreements for
    evaluation of the intended modality. 

    

    ---------------------------End of new
    text---------------------------------------
    
 

    

    
Den 2017-11-20 kl. =
21:44, skrev Gunnar
      Hellstr=C3=B6m:

    

    

     =20
      Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:

      

        
Gunnar said:=C2=A0
          


          

          
"5.4 Media, Language a=
nd
              Modality indications

          

          The combination of Language
            tags and other information in the media descriptions should
            be composed so that the intended modality can be concluded
            by the negotiating parties. "
          


            

          
[BA] Is the "should&qu=
ot;
              intended to be normative? 

            

        

      

      <GH>You are right that SHOULD should be avoided and it would
      be better to say MUST if we can. But I can imagine limited area
      applications having application agreements e.g. saying that a
      non-signed language tag in video media means a view of a talking
      person. =C2=A0 The negotiating applications know about this agreement
      so they can make the conclusion. So, if such situations can be
      included in how the parties make their conclusions, we can change
      to MUST.=C2=A0 

      

        

          


            

          
The following combinations
              of language tags and media provide obvious information
              about the modality: sign language tags in video media
              indicate signed modality...=C2=A0A sign language can be identified
              by the existence in the IANA registry of language subtags
              according to BCP 47 [RFC5646] of the language subtag with
              the Type field "extlang" combined with the Prefix f=
ield
              value "sgn".=C2=A0=C2=A0A
              specific spoken or written language can be identified by
              not having any such "sgn" Prefix.

          


            

          
Use of language may appear
              in other media, such as "message" and "applica=
tion". Video
              media may be used for other modalities than signed. Such
              use may be supported by further work or application
              specific agreements or indications for evaluation of the
              intended modality.=C2=
=A0"

            

          


            

          
[BA] Assume we can confirm
              the mechanism for distinguishing signed/non-signed
              languages, this part seems relatively solid.=C2=A0
          


            

          
spoken language tags for
              audio media indicate spoken modality and written language
              tags for text media indicate written modality. The
              examples in this specification are all from this set of
              three obvious language/media/modality combinations.
          


          

          
[BA]=C2=A0 This is where the ground gets less solid - we don=
't
            really have a general mechanism for distinguishing spoken
            and written modality among non-signed languages. Perhaps we
            should just say "language tags in audio media indicate
            spoken modality and language tags in text media indicate
            written modality". 

          

        

      

      Yes, right, that is better wording.

      

      Gunnar

      

        

          


            

            

            


            

          

        

        


          
On Mon, Nov 20, 2017 at 9:25 AM,
            Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>
            wrote:

            

              

                
It is not the signed languages that are causing the
                  problem. It is the spoken and written, when used in
                  other media than the obvious audio and text media. 

                

                
And we should specify what is obvious and well
                  defined and not, so here is a new shorter proposal for
                  section 5.4.

                
-----Old text----

                
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


                -----New text------------

                5.4 Media, Language and Modality indications

                

                The combination of Language tags and other information
                in the media descriptions should be composed so that the
                intended modality can be concluded by the negotiating
                parties. The following combinations of language tags and
                media provide obvious information about the modality:
                sign language tags in video media indicate signed
                modality, spoken language tags for audio media indicate
                spoken modality and written language tags for text media
                indicate written modality. The examples in this
                specification are all from this set of three obvious
                language/media/modality combinations.

                

                A sign language can be identified by the existence in
                the IANA registry of language subtags according to BCP
                47 [RFC5646] of the language subtag with the Type field
                "extlang" combined with the Prefix field value &q=
uot;sgn". 

                A specific spoken or written language can be identified
                by not having any such "sgn" Prefix.

                

                Use of language may appear in other media, such as
                "message" and "application". Video medi=
a may be used for
                other modalities than signed. Such use may be supported
                by further work or application specific agreements or
                indications for evaluation of the intended modality. 

                

                ------------------------------------------------------=
-------------End
                of new text---------------------------------------
                

                  


                    
Den
                      2017-11-20 kl. 15:55, skrev Randall Gellens:

                    

                    
At 7:47 PM -0800 11/19/17,
                      Bernard Aboba wrote: 

                      

                      
=C2=A0"So let's de=
lete Section
                        5.4 and be done with it.=C2=A0 Neither of the
                        statements is necessary." 

                        

                        =C2=A0[BA]=C2=A0 I agree that Section 5.4 does not =
add
                        much value as it stands. 

                        

                        =C2=A0"Non-signed" is not used outside of=
 Section
                        5.4, so there would not appear to be a need to
                        define it if Section 5.4 were to be deleted. 

                        

                        =C2=A0However, the term "signed" is used =
in 7 other
                        places in the document other than in Section
                        5.4. 

                      

                      

                      But none of those instances are normative. 

                      

                      
=C2=A0So we may need to fin=
d a
                        reference to define that term. 

                      

                      

                      Because the uses of the term are descriptive and
                      mostly background, I do not think we need to add a
                      definition or even a reference to a definition of
                      the term. 

                      

                      --Randall 

                      

                      
 

                        =C2=A0If Gunnar's suggested definition can be
                        confirmed,=C2=A0 this might be as simple as adding =
a
                        reference to the IANA language tag repository. 

                        

                        =C2=A0On Sun, Nov 19, 2017 at 3:52 PM, Randall
                        Gellens <<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy=
.pensive.org>
                        wrote: 

                        

                        =C2=A0My view of issue #43 remains that we do not
                        need to specify a mechanism for determining
                        which tags are signed.=C2=A0 In the email discussio=
n
                        of the past month or so, I fear we are drifting
                        into adding complexity rather than removing it.=C2=
=A0
                        I think the way forward is to keep this document
                        as simple as possible.=C2=A0 As Bernard notes in hi=
s
                        email of 10/23, there is no benefit in this case
                        of explicitly saying that certain things are not
                        defined.=C2=A0 Since the document does not define
                        them, they are undefined in the document. 

                        

                        =C2=A0At 6:51 PM -0700 10/23/17, Bernard Aboba wrot=
e:
                        

                        

                        =C2=A0 In other words,it is not clear to me how
                        Section 5.4's discussion of scope improves or
                        clarifies the situation in any way - and there
                        is some possibility that it could cause
                        problems. 

                        

                        

                        

                        =C2=A0I believe comment #43 should be closed as no
                        longer applicable, since the text against which
                        it was generated has been deleted. (I've said
                        this before, and I believe it remains the case.)
                        

                        

                        =C2=A0The comment from which #43 derives was made
                        against a version of the document that had text
                        explicitly discussing signed versus unsigned
                        tags.=C2=A0 That text was subsequently deleted. 
                        

                        =C2=A0Here is the comment from which #43 derived: <=
br>
                        

                        =C2=A0=C2=A0=C2=A0=C2=A0 5.2.=C2=A0 New 'humint=
lang-send' and
                        'humintlang-recv' attributes 

                        

                        =C2=A0=C2=A0=C2=A0=C2=A0 Note that while signed lan=
guage tags are
                        used with a video stream 

                        =C2=A0 to 

                        =C2=A0=C2=A0=C2=A0=C2=A0 indicate sign language, a =
spoken language
                        tag for a video stream 

                        =C2=A0 in 

                        =C2=A0=C2=A0=C2=A0=C2=A0 parallel with an audio str=
eam with the same
                        spoken language tag 

                        =C2=A0=C2=A0=C2=A0=C2=A0 indicates a request for a =
supplemental
                        video stream to see the 

                        =C2=A0=C2=A0=C2=A0=C2=A0 speaker. 

                        

                        =C2=A0 And there's a similar paragraph in 5.4: =


                        

                        =C2=A0=C2=A0=C2=A0=C2=A0 A spoken language tag for =
a video stream in
                        conjunction with an 

                        

                        =C2=A0 audio 

                        

                        =C2=A0=C2=A0=C2=A0=C2=A0 stream with the same langu=
age might
                        indicate a request for 

                        =C2=A0=C2=A0=C2=A0=C2=A0 supplemental video to see =
the speaker. 

                        

                        

                        =C2=A0 I think this mechanism needs to be described
                        more exactly, and in 

                        =C2=A0 particular, it should not depend on the UA
                        understanding which 

                        =C2=A0 language tags are spoken language tags.=C2=
=A0 It
                        seems to me that a 

                        =C2=A0 workable rule is that there is an audio stre=
am
                        and a video stream and 

                        =C2=A0 they specify exactly the same language tag i=
n
                        their respective 

                        =C2=A0 humintlang attributes.=C2=A0 In that case, i=
t is a
                        request for a spoken 

                        =C2=A0 language with simultaneous video of the
                        speaker, and those requests 

                        =C2=A0 should be considered satisfied only if both
                        streams can be 

                        =C2=A0 established. 

                        

                        

                        =C2=A0The offending text that was in 5.2 and 5.4 wa=
s
                        deleted. 

                        

                        =C2=A0The only remaining text that even mentions th=
e
                        issue is Section 5.4: 

                        

                        =C2=A0=C2=A0=C2=A0 The behavior when specifying a n=
on-signed
                        language tag for a video 

                        =C2=A0=C2=A0=C2=A0 media stream, or a signed langua=
ge tag for
                        an audio or text media 

                        =C2=A0=C2=A0=C2=A0 stream, is not defined in this d=
ocument. 

                        

                        =C2=A0=C2=A0=C2=A0 The problem of knowing which lan=
guage tags
                        are signed and which are 

                        =C2=A0=C2=A0=C2=A0 not is out of scope of this docu=
ment. 

                        

                        =C2=A0So, let's delete Section 5.4 and be done =
with
                        it.=C2=A0 Neither of the statements is necessary. <=
br>
                        

                        =C2=A0-- 

                        =C2=A0Randall Gellens 

                        =C2=A0Opinions are personal;=C2=A0=C2=A0=C2=A0 fact=
s are suspect;=C2=A0=C2=A0=C2=A0
                        I speak for myself only 

                        =C2=A0-------------- Randomly selected tag:
                        --------------- 

                        =C2=A0Make it right before you make it faster. 

                      

                      

                      

                    

                    

                  

                

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

              

            

          

          

        

      

      

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

      

      

      

      
______________________________=
_________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mai=
lman/listinfo/slim


    

    

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

  






--001a114e61a21c75f8055e71736a--


From nobody Mon Nov 20 16:44:24 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 9010312EAFF for ; Mon, 20 Nov 2017 16:44:22 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 YEJzfQ45eXlX for ; Mon, 20 Nov 2017 16:44:21 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFF712EAFA for ; Mon, 20 Nov 2017 16:44:21 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 20 Nov 2017 16:44:27 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>
X-Mailer: Eudora for Mac OS X
Date: Mon, 20 Nov 2017 16:44:19 -0800
To: Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 00:44:22 -0000

At 1:53 PM -0500 11/20/17, Paul Kyzivat wrote:

>  ISTM the real problem is with language tags in video media. These 
> could indicate that the lip motions of people in the video reflect 
> speakers of the tagged language. Or they could indicate written 
> text in the specified language is embedded in the video. (Could be 
> closed caption text or just signage.) Or (in the case of signed 
> language tags) it could indicate use of sign language in the video.

In the specific context of the draft, which is negotiating language 
and media for interactive real-time communications, I don't think 
signage or embedded written language makes sense.

>  But in the end, if this is declarative about what is being sent 
> then it isn't clear whether it is important. If it is an indication 
> of what is being requested, then it is more important.

In an offer, it's a statement of what is acceptable.  In an answer, 
it's a statement of what was selected.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A real friend isn't someone you use once and throw away.  A real
friend is someone you can use again and again.


From nobody Mon Nov 20 16:46:26 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 B910612EB04 for ; Mon, 20 Nov 2017 16:46:24 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Qz6HYLpnBTdj for ; Mon, 20 Nov 2017 16:46:23 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AB53F12EB06 for ; Mon, 20 Nov 2017 16:46:23 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 20 Nov 2017 16:46:29 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>  
X-Mailer: Eudora for Mac OS X
Date: Mon, 20 Nov 2017 16:46:21 -0800
To: Brian Rosen , Bernard Aboba 
From: Randall Gellens 
Cc: slim@ietf.org, Paul Kyzivat 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 00:46:25 -0000

At 2:19 PM -0500 11/20/17, Brian Rosen wrote:

>  We're not chartered to solve a problem like "what kind of 
> information is in a video: lip motion, sign language, captions?"
>  I think when you signal a sign language in a language tag, we all 
> know what to expect.  If you put anything else in a video stream, 
> we don't know what to expect, and this working group isn't 
> chartered to fix that.
>
>  So, say that, and only that: "Use of a language selection in a 
> video stream could have several meanings, including the use of sign 
> language and visible captions.  If a sign language is signaled in a 
> video stream, it is interpreted as the indicated sign language will 
> appear in the video .  This document does not define any other use 
> for language tags in video media."

What about just not saying anything in this draft?  Keep this draft 
simple.  I don't think that we run an interoperability risk if we 
avoid saying what we're not defining.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never call a man a fool.  Borrow from him.


From nobody Tue Nov 21 00:00:45 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 9D36412922E for ; Tue, 21 Nov 2017 00:00:43 -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 n5UYUy58HDRr for ; Tue, 21 Nov 2017 00:00:39 -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 68F1D1292D3 for ; Tue, 21 Nov 2017 00:00:38 -0800 (PST)
X-Halon-ID: 0509e9cc-ce92-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 0509e9cc-ce92-11e7-96ae-005056917f90; Tue, 21 Nov 2017 09:00:21 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>
Date: Tue, 21 Nov 2017 09:00:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------EB7419766D4AF2AC0C9A455B"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 08:00:43 -0000

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

Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
> Can we include text from Brian's suggestion? For example:
>
> "If a sign language is signaled in a video stream, it is interpreted 
> as an indication that sign language will appear in the video. A sign 
> language can be identified by the existence in the IANA registry of 
> language subtags according to BCP 47 [RFC5646] of the language subtag 
> with the Type field "extlang" combined with the Prefix field value 
> "sgn". A spoken/written language tag can be identified by not having 
> any such "sgn" prefix. This document does not define any other use for 
> language tags in video media (such as how to indicate a desire for 
> visible captions).
>
> This document does not define the use of sign language tags in text or 
> audio media. If a spoken/written language tag is included in text 
> media, it indicates a desire for written language. If a spoken/written 
> language tag is included in audio media, it is interpreted as an 
> indication that spoken language is desired.  Using the "lip sync" 
> grouping mechanism defined in [RFC5888], it is possible to indicate 
> the desire to synchronize audio and video so as to support lip reading.
>
> Use of language tags may appear in other media, such as "message" and 
> "application". Such use may be supported by further work or 
> application specific agreement."
Quite good. I see four small issues.
1: "WILL appear" is not right in the first sentence. The indication may 
be just one of a set of indicated languages.
2: The first paragraph says that we do not define other use of language 
tags in video than for sign language, but the second paragraph defines 
how to use tags for spoken language in video.
3: I prefer to start with the three normal clearly supported cases.
4: The indications sometimes indicate desire, sometimes capability. 
Therefore the word "desire" is not suitable in the explanations.
5: In the LC review, we had some resistance against using the term 
"spoken/written language tag". It appears again in the proposal. I do 
not understand the resistance and I do not know how strict it was, but 
we need to know if it is ok to use that term.  (I do not change that for 
now in the proposal below.)


A proposal trying to act on issues 1-4 plus other minor rewording:
  ---------------------------------------------------------------------------------------------------------------
5.4 Media, Language and Modality indications
A spoken/written language tag included in a text media description is an 
indication for written language. A spoken/written language tag included 
in an audio media description is an indication for spoken language. A 
sign language tag included in a video media description is an indication 
for sign language in the video stream.

A sign language can be identified by the existence in the IANA registry 
of language subtags according to BCP 47 [RFC5646] of the language subtag 
with the Type field "extlang" combined with the Prefix field value 
"sgn". A spoken/written language tag can be identified by not having any 
such "sgn" prefix.

This document does not define the use of sign language tags in text or 
audio media.  By including a language tag for spoken language in a video 
description and using the "lip sync" grouping mechanism defined in 
[RFC5888] it is possible to indicate synchronized audio and video so as 
to support lip reading. Other use of spoken/written language tags in a 
video description (such as for video embedded text captions) is not 
defined in this document.

Use of 'hlang' attributes may appear in other media descriptions, such 
as "message" and "application" supported by further work or application 
specific agreements.

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

>
>
>
> On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellström 
> > wrote:
>
>     A new proposal for new text taking in latest discussion of
>     Bernard, Paul and Brian:
>
>     -----Old text----
>
>
>           5.4 Undefined Combinations
>
>     The behavior when specifying a non-signed language tag for a video
>     media stream, or a signed language tag for an audio or text media
>     stream, is not defined in this document. The problem of knowing
>     which language tags are signed and which are not is out of scope
>     of this document.
>
>     -----New text------------
>     5.4 Media, Language and Modality indications
>
>     The combination of Language tags and other information in the
>     media descriptions shall be composed so that the intended modality
>     can be concluded by the negotiating parties. The following
>     combinations of language tags and media provide obvious
>     information about the modality: sign language tags in video media
>     indicate signed modality, language tags in audio media indicate
>     spoken modality and language tags in text media indicate written
>     modality. The examples in this specification are all from this set
>     of three obvious language/media/modality combinations.
>
>     A sign language can be identified by the existence in the IANA
>     registry of language subtags according to BCP 47 [RFC5646] of the
>     language subtag with the Type field "extlang" combined with the
>     Prefix field value "sgn".
>     A specific spoken or written language can be identified by not
>     having any such "sgn" Prefix.
>
>     Use of language may appear in other media, such as "message" and
>     "application". Video media may be used for other modalities than
>     signed, e.g. a view of a speaker or text captions. Such use may be
>     supported by further work or application specific agreements for
>     evaluation of the intended modality.
>
>     ---------------------------End of new
>     text---------------------------------------
>
>
>     Den 2017-11-20 kl. 21:44, skrev Gunnar Hellström:
>>     Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>>>     Gunnar said:
>>>
>>>     "5.4 Media, Language and Modality indications
>>>
>>>     The combination of Language tags and other information in the
>>>     media descriptions should be composed so that the intended
>>>     modality can be concluded by the negotiating parties. "
>>>
>>>     [BA] Is the "should" intended to be normative?
>>     You are right that SHOULD should be avoided and it would be
>>     better to say MUST if we can. But I can imagine limited area
>>     applications having application agreements e.g. saying that a
>>     non-signed language tag in video media means a view of a talking
>>     person.   The negotiating applications know about this agreement
>>     so they can make the conclusion. So, if such situations can be
>>     included in how the parties make their conclusions, we can change
>>     to MUST.
>>>
>>>     The following combinations of language tags and media provide
>>>     obvious information about the modality: sign language tags in
>>>     video media indicate signed modality... A sign language can be
>>>     identified by the existence in the IANA registry of language
>>>     subtags according to BCP 47 [RFC5646] of the language subtag
>>>     with the Type field "extlang" combined with the Prefix field
>>>     value "sgn". A specific spoken or written language can be
>>>     identified by not having any such "sgn" Prefix.
>>>
>>>     Use of language may appear in other media, such as "message" and
>>>     "application". Video media may be used for other modalities than
>>>     signed. Such use may be supported by further work or application
>>>     specific agreements or indications for evaluation of the
>>>     intended modality."
>>>
>>>     [BA] Assume we can confirm the mechanism for distinguishing
>>>     signed/non-signed languages, this part seems relatively solid.
>>>
>>>     spoken language tags for audio media indicate spoken modality
>>>     and written language tags for text media indicate written
>>>     modality. The examples in this specification are all from this
>>>     set of three obvious language/media/modality combinations.
>>>
>>>     [BA]  This is where the ground gets less solid - we don't really
>>>     have a general mechanism for distinguishing spoken and written
>>>     modality among non-signed languages. Perhaps we should just say
>>>     "language tags in audio media indicate spoken modality and
>>>     language tags in text media indicate written modality".
>>     Yes, right, that is better wording.
>>
>>     Gunnar
>>>
>>>
>>>
>>>
>>>
>>>     On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström
>>>     >>     > wrote:
>>>
>>>         It is not the signed languages that are causing the problem.
>>>         It is the spoken and written, when used in other media than
>>>         the obvious audio and text media.
>>>
>>>         And we should specify what is obvious and well defined and
>>>         not, so here is a new shorter proposal for section 5.4.
>>>
>>>         -----Old text----
>>>
>>>
>>>               5.4 Undefined Combinations
>>>
>>>         The behavior when specifying a non-signed language tag for a
>>>         video media stream, or a signed language tag for an audio or
>>>         text media stream, is not defined in this document. The
>>>         problem of knowing which language tags are signed and which
>>>         are not is out of scope of this document.
>>>
>>>         -----New text------------
>>>         5.4 Media, Language and Modality indications
>>>
>>>         The combination of Language tags and other information in
>>>         the media descriptions should be composed so that the
>>>         intended modality can be concluded by the negotiating
>>>         parties. The following combinations of language tags and
>>>         media provide obvious information about the modality: sign
>>>         language tags in video media indicate signed modality,
>>>         spoken language tags for audio media indicate spoken
>>>         modality and written language tags for text media indicate
>>>         written modality. The examples in this specification are all
>>>         from this set of three obvious language/media/modality
>>>         combinations.
>>>
>>>         A sign language can be identified by the existence in the
>>>         IANA registry of language subtags according to BCP 47
>>>         [RFC5646] of the language subtag with the Type field
>>>         "extlang" combined with the Prefix field value "sgn".
>>>         A specific spoken or written language can be identified by
>>>         not having any such "sgn" Prefix.
>>>
>>>         Use of language may appear in other media, such as "message"
>>>         and "application". Video media may be used for other
>>>         modalities than signed. Such use may be supported by further
>>>         work or application specific agreements or indications for
>>>         evaluation of the intended modality.
>>>
>>>         -------------------------------------------------------------------End
>>>         of new text---------------------------------------
>>>
>>>         Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>>>         At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>>
>>>>>          "So let's delete Section 5.4 and be done with it. 
>>>>>         Neither of the statements is necessary."
>>>>>
>>>>>          [BA]  I agree that Section 5.4 does not add much value as
>>>>>         it stands.
>>>>>
>>>>>          "Non-signed" is not used outside of Section 5.4, so there
>>>>>         would not appear to be a need to define it if Section 5.4
>>>>>         were to be deleted.
>>>>>
>>>>>          However, the term "signed" is used in 7 other places in
>>>>>         the document other than in Section 5.4.
>>>>
>>>>         But none of those instances are normative.
>>>>
>>>>>          So we may need to find a reference to define that term.
>>>>
>>>>         Because the uses of the term are descriptive and mostly
>>>>         background, I do not think we need to add a definition or
>>>>         even a reference to a definition of the term.
>>>>
>>>>         --Randall
>>>>
>>>>>
>>>>>          If Gunnar's suggested definition can be confirmed,  this
>>>>>         might be as simple as adding a reference to the IANA
>>>>>         language tag repository.
>>>>>
>>>>>          On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
>>>>>         <
>>>>>         rg+ietf@randy.pensive.org
>>>>>         > wrote:
>>>>>
>>>>>          My view of issue #43 remains that we do not need to
>>>>>         specify a mechanism for determining which tags are
>>>>>         signed.  In the email discussion of the past month or so,
>>>>>         I fear we are drifting into adding complexity rather than
>>>>>         removing it.  I think the way forward is to keep this
>>>>>         document as simple as possible.  As Bernard notes in his
>>>>>         email of 10/23, there is no benefit in this case of
>>>>>         explicitly saying that certain things are not defined. 
>>>>>         Since the document does not define them, they are
>>>>>         undefined in the document.
>>>>>
>>>>>          At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>>>
>>>>>           In other words,it is not clear to me how Section 5.4's
>>>>>         discussion of scope improves or clarifies the situation in
>>>>>         any way - and there is some possibility that it could
>>>>>         cause problems.
>>>>>
>>>>>
>>>>>
>>>>>          I believe comment #43 should be closed as no longer
>>>>>         applicable, since the text against which it was generated
>>>>>         has been deleted. (I've said this before, and I believe it
>>>>>         remains the case.)
>>>>>
>>>>>          The comment from which #43 derives was made against a
>>>>>         version of the document that had text explicitly
>>>>>         discussing signed versus unsigned tags.  That text was
>>>>>         subsequently deleted.
>>>>>
>>>>>          Here is the comment from which #43 derived:
>>>>>
>>>>>              5.2.  New 'humintlang-send' and 'humintlang-recv'
>>>>>         attributes
>>>>>
>>>>>              Note that while signed language tags are used with a
>>>>>         video stream
>>>>>           to
>>>>>              indicate sign language, a spoken language tag for a
>>>>>         video stream
>>>>>           in
>>>>>              parallel with an audio stream with the same spoken
>>>>>         language tag
>>>>>              indicates a request for a supplemental video stream
>>>>>         to see the
>>>>>              speaker.
>>>>>
>>>>>           And there's a similar paragraph in 5.4:
>>>>>
>>>>>              A spoken language tag for a video stream in
>>>>>         conjunction with an
>>>>>
>>>>>           audio
>>>>>
>>>>>              stream with the same language might indicate a
>>>>>         request for
>>>>>              supplemental video to see the speaker.
>>>>>
>>>>>
>>>>>           I think this mechanism needs to be described more
>>>>>         exactly, and in
>>>>>           particular, it should not depend on the UA understanding
>>>>>         which
>>>>>           language tags are spoken language tags.  It seems to me
>>>>>         that a
>>>>>           workable rule is that there is an audio stream and a
>>>>>         video stream and
>>>>>           they specify exactly the same language tag in their
>>>>>         respective
>>>>>           humintlang attributes.  In that case, it is a request
>>>>>         for a spoken
>>>>>           language with simultaneous video of the speaker, and
>>>>>         those requests
>>>>>           should be considered satisfied only if both streams can be
>>>>>           established.
>>>>>
>>>>>
>>>>>          The offending text that was in 5.2 and 5.4 was deleted.
>>>>>
>>>>>          The only remaining text that even mentions the issue is
>>>>>         Section 5.4:
>>>>>
>>>>>             The behavior when specifying a non-signed language tag
>>>>>         for a video
>>>>>             media stream, or a signed language tag for an audio or
>>>>>         text media
>>>>>             stream, is not defined in this document.
>>>>>
>>>>>             The problem of knowing which language tags are signed
>>>>>         and which are
>>>>>             not is out of scope of this document.
>>>>>
>>>>>          So, let's delete Section 5.4 and be done with it. 
>>>>>         Neither of the statements is necessary.
>>>>>
>>>>>          --
>>>>>          Randall Gellens
>>>>>          Opinions are personal;    facts are suspect;    I speak
>>>>>         for myself only
>>>>>          -------------- Randomly selected tag: ---------------
>>>>>          Make it right before you make it faster.
>>>>
>>>>
>>>
>>>         -- ----------------------------------------- Gunnar
>>>         Hellström Omnitor gunnar.hellstrom@omnitor.se
>>>          +46 708 204 288
>>>
>>>
>>
>>     -- 
>>     -----------------------------------------
>>     Gunnar Hellström
>>     Omnitor
>>     gunnar.hellstrom@omnitor.se 
>>     +46 708 204 288
>>
>>
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>>     
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     gunnar.hellstrom@omnitor.se 
>     +46 708 204 288
>
>

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


--------------EB7419766D4AF2AC0C9A455B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:

    

      
Can we include text from Brian's suggestion? For
        example: 
        


        

        
"If a sign language is
            signaled in a video stream, it is interpreted as an
            indication that sign language will appear in the video.  A sign language
            can be identified by the existence in the IANA registry of
            language subtags according to BCP 47 [RFC5646] of the
            language subtag with the Type field "extlang" combined with
            the Prefix field value "sgn".  A spoken/written language tag can
            be identified by not having any such "sgn" prefix. This document does not define any
            other use for language tags in video media (such as how to
            indicate a desire for visible captions).

        


          

        
This document does not
            define the use of sign language tags in text or audio
            media.  If a
            spoken/written language tag is included in text media, it
            indicates a desire for written language. If a spoken/written language tag is
            included in audio media, it is interpreted as an indication
            that spoken language is desired.  Using the "lip sync"
            grouping mechanism defined in [RFC5888], it is possible to
            indicate the desire to synchronize audio and video so as to
            support lip reading.

        


        

        
Use of language tags may
            appear in other media, such as "message" and "application". 
            Such use may be supported by further work or application
            specific agreement." 

          

      

    

    <GH>Quite good. I see four small issues. 

    1: "WILL appear" is not right in the first sentence. The indication
    may be just one of a set of indicated languages. 

    2: The first paragraph says that we do not define other use of
    language tags in video than for sign language, but the second
    paragraph defines how to use tags for spoken language in video. 

    3: I prefer to start with the three normal clearly supported cases.

    4: The indications sometimes indicate desire, sometimes capability.
    Therefore the word "desire" is not suitable in the explanations. 

    5: In the LC review, we had some resistance against using the term
    "spoken/written language tag". It appears again in the proposal. I
    do not understand the resistance and I do not know how strict it
    was, but we need to know if it is ok to use that term.  (I do not
    change that for now in the proposal below.)

    

    

    A proposal trying to act on issues 1-4 plus other minor rewording:

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

    5.4 Media, Language and Modality indications
    
A spoken/written language tag
            included in a text media description is an indication for
            written language. A
            spoken/written language tag included in an audio media
            description is an indication for spoken language. A
          sign language tag included in a video media description is an
          indication for sign language in the video stream.  

          

        A sign
          language can be identified by the existence in the IANA
          registry of language subtags according to BCP 47 [RFC5646] of
          the language subtag with the Type field "extlang" combined
          with the Prefix field value "sgn".  A spoken/written language tag can be
          identified by not having any such "sgn" prefix.

    


        

    
This document
          does not define the use of sign language tags in text or audio
          media.  By including a
          language tag for spoken language in a video description and
          using the "lip sync" grouping mechanism defined in [RFC5888]
          it is possible to indicate synchronized audio and video so as
          to support lip reading. Other use of spoken/written language
          tags in a video description (such as for video embedded text
          captions) is not defined in this document.

        

    


      

    Use of 'hlang'
        attributes may appear in other media descriptions, such as
        "message" and "application" supported by further work or
        application specific agreements.

    

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

    

    

      

        


          

        


        

        

      

      


        
On Mon, Nov 20, 2017 at 1:14 PM, Gunnar
          Hellström <gunnar.hellstrom@omnitor.se>
          wrote:

          

            

              
A new proposal for new text taking in latest discussion
                of Bernard, Paul and Brian:

              
                
-----Old text----

                
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


                -----New text------------

                5.4 Media, Language and Modality indications

                

               The combination of Language tags and other
              information in the media descriptions shall be composed so
              that the intended modality can be concluded by the
              negotiating parties. The following combinations of
              language tags and media provide obvious information about
              the modality: sign language tags in video media indicate
              signed modality, language tags in audio media indicate
              spoken modality and language tags in text media indicate
              written modality. The examples in this specification are
              all from this set of three obvious language/media/modality
              combinations.

                

                A sign language can be identified by the existence in
                the IANA registry of language subtags according to BCP
                47 [RFC5646] of the language subtag with the Type field
                "extlang" combined with the Prefix field value "sgn". 

                A specific spoken or written language can be identified
                by not having any such "sgn" Prefix.

                

               Use of language may appear in other media, such as
              "message" and "application". Video media may be used for
              other modalities than signed, e.g. a view of a speaker or
              text captions. Such use may be supported by further work
              or application specific agreements for evaluation of the
              intended modality. 

              

              ---------------------------End of new
              text---------------------------------------
              

                

                  
 

                  

                  
Den
                    2017-11-20 kl. 21:44, skrev Gunnar Hellström:

                  

                

              

              

                

                  
 Den 2017-11-20 kl. 19:41, skrev
                    Bernard Aboba:

                    

                      
Gunnar said: 
                        


                        

                        
"5.4 Media,
                            Language and Modality indications

                        

                        The combination
                          of Language tags and other information in the
                          media descriptions should be composed so that
                          the intended modality can be concluded by the
                          negotiating parties. "
                        


                          

                        
[BA] Is the
                            "should" intended to be normative? 

                          

                      

                    

                    <GH>You are right that SHOULD should be
                    avoided and it would be better to say MUST if we
                    can. But I can imagine limited area applications
                    having application agreements e.g. saying that a
                    non-signed language tag in video media means a view
                    of a talking person.   The negotiating applications
                    know about this agreement so they can make the
                    conclusion. So, if such situations can be included
                    in how the parties make their conclusions, we can
                    change to MUST.  

                    

                      

                        


                          

                        
The
                            following combinations of language tags and
                            media provide obvious information about the
                            modality: sign language tags in video media
                            indicate signed modality... A sign language can
                            be identified by the existence in the IANA
                            registry of language subtags according to
                            BCP 47 [RFC5646] of the language subtag with
                            the Type field "extlang" combined with the
                            Prefix field value "sgn".  A specific spoken
                            or written language can be identified by not
                            having any such "sgn" Prefix.

                        


                          

                        
Use of
                            language may appear in other media, such as
                            "message" and "application". Video media may
                            be used for other modalities than signed.
                            Such use may be supported by further work or
                            application specific agreements or
                            indications for evaluation of the intended
                            modality. "

                          

                        


                          

                        
[BA] Assume
                            we can confirm the mechanism for
                            distinguishing signed/non-signed languages,
                            this part seems relatively solid. 

                        


                          

                        
spoken
                            language tags for audio media indicate
                            spoken modality and written language tags
                            for text media indicate written modality.
                            The examples in this specification are all
                            from this set of three obvious
                            language/media/modality combinations.

                        


                        

                        
[BA]  This is where the ground gets less
                          solid - we don't really have a general
                          mechanism for distinguishing spoken and
                          written modality among non-signed languages.
                          Perhaps we should just say "language tags in
                          audio media indicate spoken modality and
                          language tags in text media indicate written
                          modality". 

                        

                      

                    

                    Yes, right, that is better wording.

                    

                    Gunnar

                    

                      

                        


                          

                          

                          


                          

                        

                      

                      


                        
On Mon, Nov 20, 2017 at
                          9:25 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se>
                          wrote:

                          

                            

                              
It is not the signed languages that are
                                causing the problem. It is the spoken
                                and written, when used in other media
                                than the obvious audio and text media. 

                              

                              
And we should specify what is obvious
                                and well defined and not, so here is a
                                new shorter proposal for section 5.4.

                              
-----Old text----

                              
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


                              -----New text------------

                              5.4 Media, Language and Modality
                              indications

                              

                              The combination of Language tags and other
                              information in the media descriptions
                              should be composed so that the intended
                              modality can be concluded by the
                              negotiating parties. The following
                              combinations of language tags and media
                              provide obvious information about the
                              modality: sign language tags in video
                              media indicate signed modality, spoken
                              language tags for audio media indicate
                              spoken modality and written language tags
                              for text media indicate written modality.
                              The examples in this specification are all
                              from this set of three obvious
                              language/media/modality combinations.

                              

                              A sign language can be identified by the
                              existence in the IANA registry of language
                              subtags according to BCP 47 [RFC5646] of
                              the language subtag with the Type field
                              "extlang" combined with the Prefix field
                              value "sgn". 

                              A specific spoken or written language can
                              be identified by not having any such "sgn"
                              Prefix.

                              

                              Use of language may appear in other media,
                              such as "message" and "application". Video
                              media may be used for other modalities
                              than signed. Such use may be supported by
                              further work or application specific
                              agreements or indications for evaluation
                              of the intended modality. 

                              

                              -------------------------------------------------------------------End
                              of new text---------------------------------------
                              

                                


                                  
Den
                                    2017-11-20 kl. 15:55, skrev Randall
                                    Gellens:

                                  

                                  
At 7:47 PM
                                    -0800 11/19/17, Bernard Aboba wrote:
                                    

                                    

                                    
 "So let's
                                      delete Section 5.4 and be done
                                      with it.  Neither of the
                                      statements is necessary." 

                                      

                                       [BA]  I agree that Section 5.4
                                      does not add much value as it
                                      stands. 

                                      

                                       "Non-signed" is not used outside
                                      of Section 5.4, so there would not
                                      appear to be a need to define it
                                      if Section 5.4 were to be deleted.
                                      

                                      

                                       However, the term "signed" is
                                      used in 7 other places in the
                                      document other than in Section
                                      5.4. 

                                    

                                    

                                    But none of those instances are
                                    normative. 

                                    

                                    
 So we may
                                      need to find a reference to define
                                      that term. 

                                    

                                    

                                    Because the uses of the term are
                                    descriptive and mostly background, I
                                    do not think we need to add a
                                    definition or even a reference to a
                                    definition of the term. 

                                    

                                    --Randall 

                                    

                                    
 

                                       If Gunnar's suggested definition
                                      can be confirmed,  this might be
                                      as simple as adding a reference to
                                      the IANA language tag repository.
                                      

                                      

                                       On Sun, Nov 19, 2017 at 3:52 PM,
                                      Randall Gellens <<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org>
                                      wrote: 

                                      

                                       My view of issue #43 remains that
                                      we do not need to specify a
                                      mechanism for determining which
                                      tags are signed.  In the email
                                      discussion of the past month or
                                      so, I fear we are drifting into
                                      adding complexity rather than
                                      removing it.  I think the way
                                      forward is to keep this document
                                      as simple as possible.  As Bernard
                                      notes in his email of 10/23, there
                                      is no benefit in this case of
                                      explicitly saying that certain
                                      things are not defined.  Since the
                                      document does not define them,
                                      they are undefined in the
                                      document. 

                                      

                                       At 6:51 PM -0700 10/23/17,
                                      Bernard Aboba wrote: 

                                      

                                        In other words,it is not clear
                                      to me how Section 5.4's discussion
                                      of scope improves or clarifies the
                                      situation in any way - and there
                                      is some possibility that it could
                                      cause problems. 

                                      

                                      

                                      

                                       I believe comment #43 should be
                                      closed as no longer applicable,
                                      since the text against which it
                                      was generated has been deleted.
                                      (I've said this before, and I
                                      believe it remains the case.) 

                                      

                                       The comment from which #43
                                      derives was made against a version
                                      of the document that had text
                                      explicitly discussing signed
                                      versus unsigned tags.  That text
                                      was subsequently deleted. 

                                      

                                       Here is the comment from which
                                      #43 derived: 

                                      

                                           5.2.  New 'humintlang-send'
                                      and 'humintlang-recv' attributes 

                                      

                                           Note that while signed
                                      language tags are used with a
                                      video stream 

                                        to 

                                           indicate sign language, a
                                      spoken language tag for a video
                                      stream 

                                        in 

                                           parallel with an audio stream
                                      with the same spoken language tag
                                      

                                           indicates a request for a
                                      supplemental video stream to see
                                      the 

                                           speaker. 

                                      

                                        And there's a similar paragraph
                                      in 5.4: 

                                      

                                           A spoken language tag for a
                                      video stream in conjunction with
                                      an 

                                      

                                        audio 

                                      

                                           stream with the same language
                                      might indicate a request for 

                                           supplemental video to see the
                                      speaker. 

                                      

                                      

                                        I think this mechanism needs to
                                      be described more exactly, and in
                                      

                                        particular, it should not depend
                                      on the UA understanding which 

                                        language tags are spoken
                                      language tags.  It seems to me
                                      that a 

                                        workable rule is that there is
                                      an audio stream and a video stream
                                      and 

                                        they specify exactly the same
                                      language tag in their respective 

                                        humintlang attributes.  In that
                                      case, it is a request for a spoken
                                      

                                        language with simultaneous video
                                      of the speaker, and those requests
                                      

                                        should be considered satisfied
                                      only if both streams can be 

                                        established. 

                                      

                                      

                                       The offending text that was in
                                      5.2 and 5.4 was deleted. 

                                      

                                       The only remaining text that even
                                      mentions the issue is Section 5.4:
                                      

                                      

                                          The behavior when specifying a
                                      non-signed language tag for a
                                      video 

                                          media stream, or a signed
                                      language tag for an audio or text
                                      media 

                                          stream, is not defined in this
                                      document. 

                                      

                                          The problem of knowing which
                                      language tags are signed and which
                                      are 

                                          not is out of scope of this
                                      document. 

                                      

                                       So, let's delete Section 5.4 and
                                      be done with it.  Neither of the
                                      statements is necessary. 

                                      

                                       -- 

                                       Randall Gellens 

                                       Opinions are personal;    facts
                                      are suspect;    I speak for myself
                                      only 

                                       -------------- Randomly selected
                                      tag: --------------- 

                                       Make it right before you make it
                                      faster. 

                                    

                                    

                                    

                                  

                                  

                                

                              

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

                            

                          

                        

                        

                      

                    

                    

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

                    

                    

                    

                  

                

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


                

              

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

              

          

        

        

      

    

    

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

  


--------------EB7419766D4AF2AC0C9A455B--


From nobody Tue Nov 21 00:26:16 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 0CF07129407 for ; Tue, 21 Nov 2017 00:26:14 -0800 (PST)
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 PWh_9DJJ1CbI for ; Tue, 21 Nov 2017 00:26:13 -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 9CBA512922E for ; Tue, 21 Nov 2017 00:26:12 -0800 (PST)
X-Halon-ID: 9a888ea0-ce95-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 9a888ea0-ce95-11e7-96ae-005056917f90; Tue, 21 Nov 2017 09:26:01 +0100 (CET)
To: Randall Gellens 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>   
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Tue, 21 Nov 2017 09:26:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 08:26:14 -0000

Den 2017-11-21 kl. 01:46, skrev Randall Gellens:

> At 2:19 PM -0500 11/20/17, Brian Rosen wrote:
>
>> We're not chartered to solve a problem like "what kind of 
>> information is in a video: lip motion, sign language, captions?"
>> I think when you signal a sign language in a language tag, we all 
>> know what to expect. If you put anything else in a video stream, we 
>> don't know what to expect, and this working group isn't chartered to 
>> fix that.
>>
>> So, say that, and only that: "Use of a language selection in a video 
>> stream could have several meanings, including the use of sign 
>> language and visible captions. If a sign language is signaled in a 
>> video stream, it is interpreted as the indicated sign language will 
>> appear in the video . This document does not define any other use 
>> for language tags in video media."
>
> What about just not saying anything in this draft? Keep this draft 
> simple. I don't think that we run an interoperability risk if we 
> avoid saying what we're not defining.
 I think it is good to specify the positive and simple cases, and 
also alert about that the use is not well defined for application and 
message media.
I think it is boiling down to a quite simple straightforward section 5.4 
now that we can agree to include.


-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


From nobody Tue Nov 21 08:03:21 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 0FE6012EB3E for ; Tue, 21 Nov 2017 08:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rFjBq1JV6rnb for ; Tue, 21 Nov 2017 08:03:11 -0800 (PST)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4CB12EBB7 for ; Tue, 21 Nov 2017 08:00:16 -0800 (PST)
Received: by mail-vk0-x236.google.com with SMTP id h21so3933851vke.7 for ; Tue, 21 Nov 2017 08:00:16 -0800 (PST)
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=DdS1UP0/WW4GLUyj/n7T50sjp/9Z0M5arpu60jLLJDI=; b=ppguadzSoOqh/s2C7qLLcxT0Kuy07QnnA/eq7SXSoWnPLjwLso8p/LE36W+O1YKqZz J4B9jt7FpjSc3tU2sXUsLTnJJiARpqiCiGNRoMGjTv6n2e3m4cyKlhEUKgSQS+RT/IPB arDC9SDChzjtq7/p2uoZMK5At5zzWUnySJzhizgU7zQFpHeSQ6VuuKAyNLe/+AmSIkIj nSPEAnjjV+xIAneyi21aI4hzb272pwI5iGNYD60yypVXUHMonR5ZiBSFMNzn9oI0JfdE Z1jlpuaOaLhwNeXCGbbMH9+j0VWCBmYPppHgeuWkUyZojOmG99U/3qKHEVYkud7+Fkav 26xw==
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=DdS1UP0/WW4GLUyj/n7T50sjp/9Z0M5arpu60jLLJDI=; b=VyM0Mqmtf5Ap5UCldAH7leAUdGxtGrRO9gT/snJpAOi+F3CiOOYy+UR9NF0Ow62l8g eEhYSfigxlTJ9fO8goz0KJhrRA6dCMA6rJi6Ls2eK1msF94lcqF8FrFVnjCvAH6PnSZK dtvlYrx4CdhCVbQC4Hb29ih0g+xAhT9iJXeszU/QLjU5rRRARwRJDd2shylsp2utLvji upuo8q+L8l7VyKN/TJrg8zSwtUJCGq3IhgO/AYWrWMkdTnAK/yg3JSmDbdjs+XZi5FwE vBDfg2qxbW/78fhUyyNLQAsiKU2LIrzBfFaoXqOXHAqqTdqefTfRehFW8Jwi8Zb5EEpu oCXA==
X-Gm-Message-State: AJaThX5MYIxroDaYtORddmtcWu2V+8bfl4IKeImlcZFLXNuayFKX7er6 E1qswzOjsvu7wxms+9BrnKJomxoN0q9BV4W5xhpC0JH2
X-Google-Smtp-Source: AGs4zMbDlzR4uMRjDuAfV5AA12jsaCngplyjKHwffXb8VEvKfuPIU6NLQPYY20BVJUAyWkIMCC6x3wY+qAynEfYEd7o=
X-Received: by 10.31.5.66 with SMTP id 63mr13587612vkf.15.1511280013967; Tue, 21 Nov 2017 08:00:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 07:59:53 -0800 (PST)
In-Reply-To: <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 07:59:53 -0800
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a1143dd5a63a9f6055e804c8e"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 16:03:20 -0000

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

[BA] LGTM.  Do you recall what the objection was to the term
"spoken/written language"?

Gunnar had said:

"A proposal trying to act on issues 1-4 plus other minor rewording:
 -----------------------------------------------------------
----------------------------------------------------
5.4 Media, Language and Modality indications
A spoken/written language tag included in a text media description is an
indication for written language. A spoken/written language tag included in
an audio media description is an indication for spoken language. A sign
language tag included in a video media description is an indication for
sign language in the video stream.

A sign language can be identified by the existence in the IANA registry of
language subtags according to BCP 47 [RFC5646] of the language subtag with
the Type field "extlang" combined with the Prefix field value "sgn".  A
spoken/written language tag can be identified by not having any such "sgn"
prefix.

This document does not define the use of sign language tags in text or
audio media.  By including a language tag for spoken language in a video
description and using the "lip sync" grouping mechanism defined in
[RFC5888] it is possible to indicate synchronized audio and video so as to
support lip reading. Other use of spoken/written language tags in a video
description (such as for video embedded text captions) is not defined in
this document.

Use of 'hlang' attributes may appear in other media descriptions, such as
"message" and "application" supported by further work or application
specific agreements."

On Tue, Nov 21, 2017 at 12:00 AM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

> Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
>
> Can we include text from Brian's suggestion? For example:
>
> "If a sign language is signaled in a video stream, it is interpreted as a=
n
> indication that sign language will appear in the video.  A sign language
> can be identified by the existence in the IANA registry of language subta=
gs
> according to BCP 47 [RFC5646] of the language subtag with the Type field
> "extlang" combined with the Prefix field value "sgn".  A spoken/written
> language tag can be identified by not having any such "sgn" prefix. This
> document does not define any other use for language tags in video media
> (such as how to indicate a desire for visible captions).
>
> This document does not define the use of sign language tags in text or
> audio media.  If a spoken/written language tag is included in text media,
> it indicates a desire for written language. If a spoken/written language
> tag is included in audio media, it is interpreted as an indication that
> spoken language is desired.  Using the "lip sync" grouping mechanism
> defined in [RFC5888], it is possible to indicate the desire to synchroniz=
e
> audio and video so as to support lip reading.
>
> Use of language tags may appear in other media, such as "message" and
> "application".  Such use may be supported by further work or application
> specific agreement."
>
> Quite good. I see four small issues.
> 1: "WILL appear" is not right in the first sentence. The indication may b=
e
> just one of a set of indicated languages.
> 2: The first paragraph says that we do not define other use of language
> tags in video than for sign language, but the second paragraph defines ho=
w
> to use tags for spoken language in video.
> 3: I prefer to start with the three normal clearly supported cases.
> 4: The indications sometimes indicate desire, sometimes capability.
> Therefore the word "desire" is not suitable in the explanations.
> 5: In the LC review, we had some resistance against using the term
> "spoken/written language tag". It appears again in the proposal. I do not
> understand the resistance and I do not know how strict it was, but we nee=
d
> to know if it is ok to use that term.  (I do not change that for now in t=
he
> proposal below.)
>
>
> A proposal trying to act on issues 1-4 plus other minor rewording:
>  -----------------------------------------------------------
> ----------------------------------------------------
> 5.4 Media, Language and Modality indications
> A spoken/written language tag included in a text media description is an
> indication for written language. A spoken/written language tag included
> in an audio media description is an indication for spoken language. A
> sign language tag included in a video media description is an indication
> for sign language in the video stream.
>
> A sign language can be identified by the existence in the IANA registry o=
f
> language subtags according to BCP 47 [RFC5646] of the language subtag wit=
h
> the Type field "extlang" combined with the Prefix field value "sgn".  A
> spoken/written language tag can be identified by not having any such "sgn=
"
> prefix.
>
> This document does not define the use of sign language tags in text or
> audio media.  By including a language tag for spoken language in a video
> description and using the "lip sync" grouping mechanism defined in
> [RFC5888] it is possible to indicate synchronized audio and video so as t=
o
> support lip reading. Other use of spoken/written language tags in a video
> description (such as for video embedded text captions) is not defined in
> this document.
>
> Use of 'hlang' attributes may appear in other media descriptions, such as
> "message" and "application" supported by further work or application
> specific agreements.
>
> ------------------------------------------------------------------
>
>
>
>
>
> On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellstr=C3=B6m <
> gunnar.hellstrom@omnitor.se> wrote:
>
>> A new proposal for new text taking in latest discussion of Bernard, Paul
>> and Brian:
>>
>> -----Old text----
>>
>> 5.4 Undefined Combinations
>>
>>    The behavior when specifying a non-signed language tag for a video
>>    media stream, or a signed language tag for an audio or text media
>>    stream, is not defined in this document.
>>
>>    The problem of knowing which language tags are signed and which are
>>    not is out of scope of this document.
>>
>> -----New text------------
>> 5.4 Media, Language and Modality indications
>>
>> The combination of Language tags and other information in the media
>> descriptions shall be composed so that the intended modality can be
>> concluded by the negotiating parties. The following combinations of
>> language tags and media provide obvious information about the modality:
>> sign language tags in video media indicate signed modality, language tag=
s
>> in audio media indicate spoken modality and language tags in text media
>> indicate written modality. The examples in this specification are all fr=
om
>> this set of three obvious language/media/modality combinations.
>>
>> A sign language can be identified by the existence in the IANA registry
>> of language subtags according to BCP 47 [RFC5646] of the language subtag
>> with the Type field "extlang" combined with the Prefix field value "sgn"=
.
>> A specific spoken or written language can be identified by not having an=
y
>> such "sgn" Prefix.
>>
>> Use of language may appear in other media, such as "message" and
>> "application". Video media may be used for other modalities than signed,
>> e.g. a view of a speaker or text captions. Such use may be supported by
>> further work or application specific agreements for evaluation of the
>> intended modality.
>>
>> ---------------------------End of new text------------------------------=
---------
>>
>>
>>
>> Den 2017-11-20 kl. 21:44, skrev Gunnar Hellstr=C3=B6m:
>>
>> Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>>
>> Gunnar said:
>>
>> "5.4 Media, Language and Modality indications
>>
>> The combination of Language tags and other information in the media
>> descriptions should be composed so that the intended modality can be
>> concluded by the negotiating parties. "
>>
>> [BA] Is the "should" intended to be normative?
>>
>> You are right that SHOULD should be avoided and it would be better t=
o
>> say MUST if we can. But I can imagine limited area applications having
>> application agreements e.g. saying that a non-signed language tag in vid=
eo
>> media means a view of a talking person.   The negotiating applications k=
now
>> about this agreement so they can make the conclusion. So, if such
>> situations can be included in how the parties make their conclusions, we
>> can change to MUST.
>>
>>
>> The following combinations of language tags and media provide obvious
>> information about the modality: sign language tags in video media indica=
te
>> signed modality... A sign language can be identified by the existence in
>> the IANA registry of language subtags according to BCP 47 [RFC5646] of t=
he
>> language subtag with the Type field "extlang" combined with the Prefix
>> field value "sgn".  A specific spoken or written language can be
>> identified by not having any such "sgn" Prefix.
>>
>> Use of language may appear in other media, such as "message" and
>> "application". Video media may be used for other modalities than signed.
>> Such use may be supported by further work or application specific
>> agreements or indications for evaluation of the intended modality. "
>>
>> [BA] Assume we can confirm the mechanism for distinguishing
>> signed/non-signed languages, this part seems relatively solid.
>>
>> spoken language tags for audio media indicate spoken modality and writte=
n
>> language tags for text media indicate written modality. The examples in
>> this specification are all from this set of three obvious
>> language/media/modality combinations.
>>
>> [BA]  This is where the ground gets less solid - we don't really have a
>> general mechanism for distinguishing spoken and written modality among
>> non-signed languages. Perhaps we should just say "language tags in audio
>> media indicate spoken modality and language tags in text media indicate
>> written modality".
>>
>> Yes, right, that is better wording.
>>
>> Gunnar
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellstr=C3=B6m <
>> gunnar.hellstrom@omnitor.se> wrote:
>>
>>> It is not the signed languages that are causing the problem. It is the
>>> spoken and written, when used in other media than the obvious audio and
>>> text media.
>>>
>>> And we should specify what is obvious and well defined and not, so here
>>> is a new shorter proposal for section 5.4.
>>>
>>> -----Old text----
>>>
>>> 5.4 Undefined Combinations
>>>
>>>    The behavior when specifying a non-signed language tag for a video
>>>    media stream, or a signed language tag for an audio or text media
>>>    stream, is not defined in this document.
>>>
>>>    The problem of knowing which language tags are signed and which are
>>>    not is out of scope of this document.
>>>
>>> -----New text------------
>>> 5.4 Media, Language and Modality indications
>>>
>>> The combination of Language tags and other information in the media
>>> descriptions should be composed so that the intended modality can be
>>> concluded by the negotiating parties. The following combinations of
>>> language tags and media provide obvious information about the modality:
>>> sign language tags in video media indicate signed modality, spoken lang=
uage
>>> tags for audio media indicate spoken modality and written language tags=
 for
>>> text media indicate written modality. The examples in this specificatio=
n
>>> are all from this set of three obvious language/media/modality combinat=
ions.
>>>
>>> A sign language can be identified by the existence in the IANA registry
>>> of language subtags according to BCP 47 [RFC5646] of the language subta=
g
>>> with the Type field "extlang" combined with the Prefix field value "sgn=
".
>>> A specific spoken or written language can be identified by not having
>>> any such "sgn" Prefix.
>>>
>>> Use of language may appear in other media, such as "message" and
>>> "application". Video media may be used for other modalities than signed=
.
>>> Such use may be supported by further work or application specific
>>> agreements or indications for evaluation of the intended modality.
>>>
>>> -------------------------------------------------------------------End
>>> of new text---------------------------------------
>>>
>>> Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>>
>>> At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>
>>>  "So let's delete Section 5.4 and be done with it.  Neither of the
>>> statements is necessary."
>>>
>>>  [BA]  I agree that Section 5.4 does not add much value as it stands.
>>>
>>>  "Non-signed" is not used outside of Section 5.4, so there would not
>>> appear to be a need to define it if Section 5.4 were to be deleted.
>>>
>>>  However, the term "signed" is used in 7 other places in the document
>>> other than in Section 5.4.
>>>
>>>
>>> But none of those instances are normative.
>>>
>>>  So we may need to find a reference to define that term.
>>>
>>>
>>> Because the uses of the term are descriptive and mostly background, I d=
o
>>> not think we need to add a definition or even a reference to a definiti=
on
>>> of the term.
>>>
>>> --Randall
>>>
>>>
>>>  If Gunnar's suggested definition can be confirmed,  this might be as
>>> simple as adding a reference to the IANA language tag repository.
>>>
>>>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens <
>>>  
>>> rg+ietf@randy.pensive.org> wrote:
>>>
>>>  My view of issue #43 remains that we do not need to specify a mechanis=
m
>>> for determining which tags are signed.  In the email discussion of the =
past
>>> month or so, I fear we are drifting into adding complexity rather than
>>> removing it.  I think the way forward is to keep this document as simpl=
e as
>>> possible.  As Bernard notes in his email of 10/23, there is no benefit =
in
>>> this case of explicitly saying that certain things are not defined.  Si=
nce
>>> the document does not define them, they are undefined in the document.
>>>
>>>  At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>
>>>   In other words,it is not clear to me how Section 5.4's discussion of
>>> scope improves or clarifies the situation in any way - and there is som=
e
>>> possibility that it could cause problems.
>>>
>>>
>>>
>>>  I believe comment #43 should be closed as no longer applicable, since
>>> the text against which it was generated has been deleted. (I've said th=
is
>>> before, and I believe it remains the case.)
>>>
>>>  The comment from which #43 derives was made against a version of the
>>> document that had text explicitly discussing signed versus unsigned tag=
s.
>>> That text was subsequently deleted.
>>>
>>>  Here is the comment from which #43 derived:
>>>
>>>      5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>>
>>>      Note that while signed language tags are used with a video stream
>>>   to
>>>      indicate sign language, a spoken language tag for a video stream
>>>   in
>>>      parallel with an audio stream with the same spoken language tag
>>>      indicates a request for a supplemental video stream to see the
>>>      speaker.
>>>
>>>   And there's a similar paragraph in 5.4:
>>>
>>>      A spoken language tag for a video stream in conjunction with an
>>>
>>>   audio
>>>
>>>      stream with the same language might indicate a request for
>>>      supplemental video to see the speaker.
>>>
>>>
>>>   I think this mechanism needs to be described more exactly, and in
>>>   particular, it should not depend on the UA understanding which
>>>   language tags are spoken language tags.  It seems to me that a
>>>   workable rule is that there is an audio stream and a video stream and
>>>   they specify exactly the same language tag in their respective
>>>   humintlang attributes.  In that case, it is a request for a spoken
>>>   language with simultaneous video of the speaker, and those requests
>>>   should be considered satisfied only if both streams can be
>>>   established.
>>>
>>>
>>>  The offending text that was in 5.2 and 5.4 was deleted.
>>>
>>>  The only remaining text that even mentions the issue is Section 5.4:
>>>
>>>     The behavior when specifying a non-signed language tag for a video
>>>     media stream, or a signed language tag for an audio or text media
>>>     stream, is not defined in this document.
>>>
>>>     The problem of knowing which language tags are signed and which are
>>>     not is out of scope of this document.
>>>
>>>  So, let's delete Section 5.4 and be done with it.  Neither of the
>>> statements is necessary.
>>>
>>>  --
>>>  Randall Gellens
>>>  Opinions are personal;    facts are suspect;    I speak for myself onl=
y
>>>  -------------- Randomly selected tag: ---------------
>>>  Make it right before you make it faster.
>>>
>>>
>>>
>>>
>>> --
>>> -----------------------------------------
>>> Gunnar Hellstr=C3=B6m
>>> Omnitorgunnar.hellstrom@omnitor.se
>>> +46 708 204 288
>>>
>>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitorgunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>>
>> _______________________________________________
>> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellstr=C3=B6m
>> Omnitorgunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>

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


[BA] LGTM.=C2=A0 Do you recall what the objection was to t=
he term "spoken/written language"?

Gunnar had =
said:=C2=A0

"A pro=
posal trying to act on issues 1-4 plus other minor rewording:
<=
span style=3D"font-size:12.8px">=C2=A0-----------------------------<=
wbr style=3D"font-size:12.8px">-----------=
-----------------------------------------------------------------------
5.4 Media, Language an=
d Modality indications
=
A spoken/written language tag included in a text media description is an in=
dication for written language.=C2=A0A spoken/written language tag included in an audio media description is an=
 indication for spoken language. A=C2=A0sign language tag included i=
n a video media description is an indication for sign language in the video=
 stream.=C2=A0=C2=A0

A sign language can be identified by the existence in the=
 IANA registry of language subtags according to BCP 47 [RFC5646] of the lan=
guage subtag with the Type field "extlang" combined with the Pref=
ix field value "sgn".=C2=A0=C2=A0A spoken/written language t=
ag can be identified by not having any such "sgn" prefix.<=
span style=3D"font-size:12.8px">

This document does not define the use of sign langu=
age tags in text or audio media.=C2=
=A0 By including a language tag for spoken language in a video description =
and using the "lip sync" grouping mechanism defined in [RFC5888] =
it is possible to indicate synchronized audio and video so as to support li=
p reading. Other use of spoken/written language tags in a video description=
 (such as for video embedded text captions) is not defined in this document=
.
=

Use of 'hlang=
9; attributes may appear in other media descriptions, such as "message=
" and "application" supported by further work or application=
 specific agreements."

On Tue, Nov 21, 2017 at 12:00 AM, Gunnar=
 Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrot=
e:

 =20
   =20
 =20
  

    Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:

    

      
Can we include text from Brian's suggestion? For
        example:=C2=A0
        


        

        
"If a sign language is
            signaled in a video stream, it is interpreted as an
            indication that sign language will appear in the video.=C2=A0=
=C2=A0A sign lan=
guage
            can be identified by the existence in the IANA registry of
            language subtags according to BCP 47 [RFC5646] of the
            language subtag with the Type field "extlang" combine=
d with
            the Prefix field value "sgn".=C2=A0=C2=A0A spoke=
n/written language tag can
            be identified by not having any such "sgn" prefix.=C2=
=A0This document does not define any
            other use for language tags in video media (such as how to
            indicate a desire for visible captions).

        


          

        
This document does not
            define the use of sign language tags in text or audio
            media.=C2=A0=C2=A0If a
            spoken/written language tag is included in text media, it
            indicates a desire for written language.=C2=A0If a spoken/written language tag is
            included in audio media, it is interpreted as an indication
            that spoken language is desired.=C2=A0 Using the "lip sync=
"
            grouping mechanism defined in [RFC5888], it is possible to
            indicate the desire to synchronize audio and video so as to
            support lip reading.

        


        

        
Use of language tags may
            appear in other media, such as "message" and "ap=
plication".=C2=A0
            Such use may be supported by further work or application
            specific agreement." 

          

      

    

    <GH>Quite good. I see four small issues. 

    1: "WILL appear" is not right in the first sentence. The indi=
cation
    may be just one of a set of indicated languages. 

    2: The first paragraph says that we do not define other use of
    language tags in video than for sign language, but the second
    paragraph defines how to use tags for spoken language in video. 

    3: I prefer to start with the three normal clearly supported cases.

    4: The indications sometimes indicate desire, sometimes capability.
    Therefore the word "desire" is not suitable in the explanatio=
ns. 

    5: In the LC review, we had some resistance against using the term
    "spoken/written language tag". It appears again in the propos=
al. I
    do not understand the resistance and I do not know how strict it
    was, but we need to know if it is ok to use that term.=C2=A0 (I do not
    change that for now in the proposal below.)

    

    

    A proposal trying to act on issues 1-4 plus other minor rewording:

=C2=A0-----------------------------------------------------------=
----------------------------------------------------<=
br>
    5.4 Media, Language and Modality indications
    
<=
span style=3D"font-size:12.8px">A spoken/written language tag
            included in a text media description is an indication for
            written language. A
            spoken/written language tag included in an audio media
            description is an indication for spoken language. A
          sign language tag included in a video media description is an
          indication for sign language in the video stream.=C2=A0 

          

        A sign
          language can be identified by the existence in the IANA
          registry of language subtags according to BCP 47 [RFC5646] of
          the language subtag with the Type field "extlang" combi=
ned
          with the Prefix field value "sgn".=C2=A0=C2=A0A sp=
oken/written language tag can be
          identified by not having any such "sgn" prefix.<=
span style=3D"font-size:12.8px">

    


        

    
This document
          does not define the use of sign language tags in text or audio
          media.=C2=A0 By including=
 a
          language tag for spoken language in a video description and
          using the "lip sync" grouping mechanism defined in [RFC=
5888]
          it is possible to indicate synchronized audio and video so as
          to support lip reading. Other use of spoken/written language
          tags in a video description (such as for video embedded text
          captions) is not defined in this document.

        

    


      

    Use of 'hlang=
9;
        attributes may appear in other media descriptions, such as
        "message" and "application" supported by furthe=
r work or
        application specific agreements.

    

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


    

    

      

        


          

        


        

        

      

      


        
On Mon, Nov 20, 2017 at 1:14 PM, Gunnar
          Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se>
          wrote:

          

            

              
A new proposal for new text taking in latest discussion
                of Bernard, Paul and Brian:

              
                
-----Old text----

                
5.4 Unde=
fined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


                -----New text------------

                5.4 Media, Language and Modality indications

                

               The combination of Language tags and other
              information in the media descriptions shall be composed so
              that the intended modality can be concluded by the
              negotiating parties. The following combinations of
              language tags and media provide obvious information about
              the modality: sign language tags in video media indicate
              signed modality, language tags in audio media indicate
              spoken modality and language tags in text media indicate
              written modality. The examples in this specification are
              all from this set of three obvious language/media/modality
              combinations.

                

                A sign language can be identified by the existence in
                the IANA registry of language subtags according to BCP
                47 [RFC5646] of the language subtag with the Type field
                "extlang" combined with the Prefix field value &q=
uot;sgn". 

                A specific spoken or written language can be identified
                by not having any such "sgn" Prefix.

                

               Use of language may appear in other media, such as
              "message" and "application". Video media =
may be used for
              other modalities than signed, e.g. a view of a speaker or
              text captions. Such use may be supported by further work
              or application specific agreements for evaluation of the
              intended modality. 

              

              ---------------------------End of new
              text---------------------------------------
              

                

                  
 

                  

                  
Den
                    2017-11-20 kl. 21:44, skrev Gunnar Hellstr=C3=B6m:

                  

                

              

              

                

                  
 Den 2017-11-20 kl=
. 19:41, skrev
                    Bernard Aboba:

                    

                      
Gunnar said:=C2=A0
                        


                        

                        
"5.4 Med=
ia,
                            Language and Modality indications

                        

                        The combination
                          of Language tags and other information in the
                          media descriptions should be composed so that
                          the intended modality can be concluded by the
                          negotiating parties. "
                        


                          

                        
[BA] Is the
                            "should" intended to be normative? 
                          

                      

                    

                    <GH>You are right that SHOULD should be
                    avoided and it would be better to say MUST if we
                    can. But I can imagine limited area applications
                    having application agreements e.g. saying that a
                    non-signed language tag in video media means a view
                    of a talking person. =C2=A0 The negotiating application=
s
                    know about this agreement so they can make the
                    conclusion. So, if such situations can be included
                    in how the parties make their conclusions, we can
                    change to MUST.=C2=A0 

                    

                      

                        


                          

                        
The
                            following combinations of language tags and
                            media provide obvious information about the
                            modality: sign language tags in video media
                            indicate signed modality...=C2=A0A sign language can
                            be identified by the existence in the IANA
                            registry of language subtags according to
                            BCP 47 [RFC5646] of the language subtag with
                            the Type field "extlang" combined wit=
h the
                            Prefix field value "sgn".=C2=A0=C2=A0=
A specific spoken
                            or written language can be identified by not
                            having any such "sgn" Prefix.<=
/div>
                        


                          

                        
Use of
                            language may appear in other media, such as
                            "message" and "application"=
. Video media may
                            be used for other modalities than signed.
                            Such use may be supported by further work or
                            application specific agreements or
                            indications for evaluation of the intended
                            modality.=C2=A0"

                          

                        


                          

                        
[BA] Assume
                            we can confirm the mechanism for
                            distinguishing signed/non-signed languages,
                            this part seems relatively solid.=C2=A0<=
/div>
                        


                          

                        
spoken
                            language tags for audio media indicate
                            spoken modality and written language tags
                            for text media indicate written modality.
                            The examples in this specification are all
                            from this set of three obvious
                            language/media/modality combinations.
                        


                        

                        
[BA]=C2=A0 This is where the ground gets less
                          solid - we don't really have a general
                          mechanism for distinguishing spoken and
                          written modality among non-signed languages.
                          Perhaps we should just say "language tags in
                          audio media indicate spoken modality and
                          language tags in text media indicate written
                          modality". 

                        

                      

                    

                    Yes, right, that is better wording.

                    

                    Gunnar

                    

                      

                        


                          

                          

                          


                          

                        

                      

                      


                        
On Mon, Nov 20, 2017 at
                          9:25 AM, Gunnar Hellstr=C3=B6m =
<gunnar=
.hellstrom@omnitor.se>
                          wrote:

                          

                            

                              
It is not the signed languages that are
                                causing the problem. It is the spoken
                                and written, when used in other media
                                than the obvious audio and text media. 

                              

                              
And we should specify what is obvious
                                and well defined and not, so here is a
                                new shorter proposal for section 5.4.

                              
-----Old text----

                              
5.4 Undefined Combinations


   The behavior when specifying a non-signed language tag for a video
   media stream, or a signed language tag for an audio or text media
   stream, is not defined in this document.

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.


                              -----New text------------

                              5.4 Media, Language and Modality
                              indications

                              

                              The combination of Language tags and other
                              information in the media descriptions
                              should be composed so that the intended
                              modality can be concluded by the
                              negotiating parties. The following
                              combinations of language tags and media
                              provide obvious information about the
                              modality: sign language tags in video
                              media indicate signed modality, spoken
                              language tags for audio media indicate
                              spoken modality and written language tags
                              for text media indicate written modality.
                              The examples in this specification are all
                              from this set of three obvious
                              language/media/modality combinations.

                              

                              A sign language can be identified by the
                              existence in the IANA registry of language
                              subtags according to BCP 47 [RFC5646] of
                              the language subtag with the Type field
                              "extlang" combined with the Prefix =
field
                              value "sgn". 

                              A specific spoken or written language can
                              be identified by not having any such "sg=
n"
                              Prefix.

                              

                              Use of language may appear in other media,
                              such as "message" and "applica=
tion". Video
                              media may be used for other modalities
                              than signed. Such use may be supported by
                              further work or application specific
                              agreements or indications for evaluation
                              of the intended modality. 

                              

                              ----------------------------------------=
---------------------------End
                              of new text-----------------------------=
----------
                              

                                


                                  
Den
                                    2017-11-20 kl. 15:55, skrev Randall
                                    Gellens:

                                  

                                  
At 7:47 PM
                                    -0800 11/19/17, Bernard Aboba wrote:
                                    

                                    

                                    
=C2=A0"S=
o let's
                                      delete Section 5.4 and be done
                                      with it.=C2=A0 Neither of the
                                      statements is necessary." 

                                      

                                      =C2=A0[BA]=C2=A0 I agree that Section=
 5.4
                                      does not add much value as it
                                      stands. 

                                      

                                      =C2=A0"Non-signed" is not u=
sed outside
                                      of Section 5.4, so there would not
                                      appear to be a need to define it
                                      if Section 5.4 were to be deleted.
                                      

                                      

                                      =C2=A0However, the term "signed&=
quot; is
                                      used in 7 other places in the
                                      document other than in Section
                                      5.4. 

                                    

                                    

                                    But none of those instances are
                                    normative. 

                                    

                                    
=C2=A0So we m=
ay
                                      need to find a reference to define
                                      that term. 

                                    

                                    

                                    Because the uses of the term are
                                    descriptive and mostly background, I
                                    do not think we need to add a
                                    definition or even a reference to a
                                    definition of the term. 

                                    

                                    --Randall 

                                    

                                    
 

                                      =C2=A0If Gunnar's suggested defin=
ition
                                      can be confirmed,=C2=A0 this might be
                                      as simple as adding a reference to
                                      the IANA language tag repository.
                                      

                                      

                                      =C2=A0On Sun, Nov 19, 2017 at 3:52 PM=
,
                                      Randall Gellens <<mailt=
o:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.or=
g>
                                      wrote: 

                                      

                                      =C2=A0My view of issue #43 remains th=
at
                                      we do not need to specify a
                                      mechanism for determining which
                                      tags are signed.=C2=A0 In the email
                                      discussion of the past month or
                                      so, I fear we are drifting into
                                      adding complexity rather than
                                      removing it.=C2=A0 I think the way
                                      forward is to keep this document
                                      as simple as possible.=C2=A0 As Berna=
rd
                                      notes in his email of 10/23, there
                                      is no benefit in this case of
                                      explicitly saying that certain
                                      things are not defined.=C2=A0 Since t=
he
                                      document does not define them,
                                      they are undefined in the
                                      document. 

                                      

                                      =C2=A0At 6:51 PM -0700 10/23/17,
                                      Bernard Aboba wrote: 

                                      

                                      =C2=A0 In other words,it is not clear
                                      to me how Section 5.4's discussio=
n
                                      of scope improves or clarifies the
                                      situation in any way - and there
                                      is some possibility that it could
                                      cause problems. 

                                      

                                      

                                      

                                      =C2=A0I believe comment #43 should be
                                      closed as no longer applicable,
                                      since the text against which it
                                      was generated has been deleted.
                                      (I've said this before, and I
                                      believe it remains the case.) 

                                      

                                      =C2=A0The comment from which #43
                                      derives was made against a version
                                      of the document that had text
                                      explicitly discussing signed
                                      versus unsigned tags.=C2=A0 That text
                                      was subsequently deleted. 

                                      

                                      =C2=A0Here is the comment from which
                                      #43 derived: 

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0 5.2.=C2=A0 N=
ew 'humintlang-send'
                                      and 'humintlang-recv' attribu=
tes 

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0 Note that wh=
ile signed
                                      language tags are used with a
                                      video stream 

                                      =C2=A0 to 

                                      =C2=A0=C2=A0=C2=A0=C2=A0 indicate sig=
n language, a
                                      spoken language tag for a video
                                      stream 

                                      =C2=A0 in 

                                      =C2=A0=C2=A0=C2=A0=C2=A0 parallel wit=
h an audio stream
                                      with the same spoken language tag
                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0 indicates a =
request for a
                                      supplemental video stream to see
                                      the 

                                      =C2=A0=C2=A0=C2=A0=C2=A0 speaker. 
                                      

                                      =C2=A0 And there's a similar para=
graph
                                      in 5.4: 

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0 A spoken lan=
guage tag for a
                                      video stream in conjunction with
                                      an 

                                      

                                      =C2=A0 audio 

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0 stream with =
the same language
                                      might indicate a request for 

                                      =C2=A0=C2=A0=C2=A0=C2=A0 supplemental=
 video to see the
                                      speaker. 

                                      

                                      

                                      =C2=A0 I think this mechanism needs t=
o
                                      be described more exactly, and in
                                      

                                      =C2=A0 particular, it should not depe=
nd
                                      on the UA understanding which 

                                      =C2=A0 language tags are spoken
                                      language tags.=C2=A0 It seems to me
                                      that a 

                                      =C2=A0 workable rule is that there is
                                      an audio stream and a video stream
                                      and 

                                      =C2=A0 they specify exactly the same
                                      language tag in their respective 

                                      =C2=A0 humintlang attributes.=C2=A0 I=
n that
                                      case, it is a request for a spoken
                                      

                                      =C2=A0 language with simultaneous vid=
eo
                                      of the speaker, and those requests
                                      

                                      =C2=A0 should be considered satisfied
                                      only if both streams can be 

                                      =C2=A0 established. 

                                      

                                      

                                      =C2=A0The offending text that was in
                                      5.2 and 5.4 was deleted. 

                                      

                                      =C2=A0The only remaining text that ev=
en
                                      mentions the issue is Section 5.4:
                                      

                                      

                                      =C2=A0=C2=A0=C2=A0 The behavior when =
specifying a
                                      non-signed language tag for a
                                      video 

                                      =C2=A0=C2=A0=C2=A0 media stream, or a=
 signed
                                      language tag for an audio or text
                                      media 

                                      =C2=A0=C2=A0=C2=A0 stream, is not def=
ined in this
                                      document. 

                                      

                                      =C2=A0=C2=A0=C2=A0 The problem of kno=
wing which
                                      language tags are signed and which
                                      are 

                                      =C2=A0=C2=A0=C2=A0 not is out of scop=
e of this
                                      document. 

                                      

                                      =C2=A0So, let's delete Section 5.=
4 and
                                      be done with it.=C2=A0 Neither of the
                                      statements is necessary. 

                                      

                                      =C2=A0-- 

                                      =C2=A0Randall Gellens 

                                      =C2=A0Opinions are personal;=C2=A0=C2=
=A0=C2=A0 facts
                                      are suspect;=C2=A0=C2=A0=C2=A0 I spea=
k for myself
                                      only 

                                      =C2=A0-------------- Randomly selecte=
d
                                      tag: --------------- 

                                      =C2=A0Make it right before you make i=
t
                                      faster. 

                                    

                                    

                                    

                                  

                                  

                                

                              

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

                            

                          

                        

                        

                      

                    

                    

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

                    

                    

                    

                  

                

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


                

              

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

              

          

        

        

      

    

    

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

  






--001a1143dd5a63a9f6055e804c8e--


From nobody Tue Nov 21 08:44:17 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 448AA129B15 for ; Tue, 21 Nov 2017 08:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 unZDhvAuPEQ0 for ; Tue, 21 Nov 2017 08:44:15 -0800 (PST)
Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id A45C4129B08 for ; Tue, 21 Nov 2017 08:44:14 -0800 (PST)
X-AuditID: 12074411-f7dff70000007f0a-82-5a1457dd1fe1
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 10.8A.32522.DD7541A5; Tue, 21 Nov 2017 11:44:13 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vALGiCEP000942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Nov 2017 11:44:13 -0500
To: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se> 
From: Paul Kyzivat 
Message-ID: <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>
Date: Tue, 21 Nov 2017 11:44:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYndR1L0XLhJlcP4ik8XMD51sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6FhxmbGgnb1ixr129gbGLaxdjJwcEgImEjfmrGXrYuTiEBLY wSRx7+Z9ZgjnK5PEjUsvGEGqhAWCJC5OfcYGYosICEp875nBBFHUwyrxctIjFpAEm4CWxJxD /8FsXgF7if7+p2ANLAKqEmsnTgezRQXSJO7MeMgEUSMocXLmE6B6Dg5OgUCJmb1xIGFmATOJ eZsfMkPY4hK3nsxngrDlJZq3zmaewMg/C0n3LCQts5C0zELSsoCRZRWjXGJOaa5ubmJmTnFq sm5xcmJeXmqRrqlebmaJXmpK6SZGSFgK7mCccVLuEKMAB6MSD+8OY5EoIdbEsuLK3EOMkhxM SqK8kqZAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8mbJAOd6UxMqq1KJ8mJQ0B4uSOC/fEnU/ IYH0xJLU7NTUgtQimKwMB4eSBO+fMKBGwaLU9NSKtMycEoQ0EwcnyHAeoOFbQGp4iwsSc4sz 0yHypxjtOW48vP6HiaOn5waQfHTjLpB8NvN1A7MQS15+XqqUOC8vSJsASFtGaR7cZFjKecUo DvSoMO8ykCoeYLqCm/0KaC0T0Nqfx4VB1pYkIqSkGhgX+u4112XatGlu7ouTpx5nz45eIHRn wbxmMZakZ4c2/dhm694if1c5Tiu1qJllzbsfolV1524LPTi3++jZ9k0/p/gq3zvE4LlpvWLU 57t8OoxvJk++GZvYHdnEv6mqID5FOfBP/By+GbN29p52FFp2uWXOPM/SYzc6nn8PZnHoirQO uqMzoemDEktxRqKhFnNRcSIAJBgnlRQDAAA=
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 16:44:16 -0000

On 11/21/17 10:59 AM, Bernard Aboba wrote:
> [BA] LGTM.  Do you recall what the objection was to the term 
> "spoken/written language"?
> 
> Gunnar had said:
> 
> By including a language tag for spoken language in a video 
> description and using the "lip sync" grouping mechanism defined in 
> [RFC5888] it is possible to indicate synchronized audio and video so as 
> to support lip reading. 

When using lip sync, is there any necessity to put the language tag on 
the video? ISTM that is irrelevant, as long as it is on the synced audio 
media. ISTM it would be better to say:

    By including a language tag for spoken language in an audio
    description and using the "lip sync" grouping mechanism defined
    in [RFC5888] to group it with a video media stream it is possible
    to indicate synchronized audio and video so as to support lip
    reading.

	Thanks,
	Paul


From nobody Tue Nov 21 09:07: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 28E4F129B2C for ; Tue, 21 Nov 2017 09:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UM6ycG-ptlao for ; Tue, 21 Nov 2017 09:07:17 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9973A129AC6 for ; Tue, 21 Nov 2017 09:07:17 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id j14so8706905uag.11 for ; Tue, 21 Nov 2017 09:07:17 -0800 (PST)
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=jMsUGuppfDlOyXbgS73olb928sYiJavNJCOGm378cWc=; b=auwL94T++JgAZ3vvwRDWOgc0YxOE9eJlj5QwWvB0RtliP4ADHvNfHUEqJ+U1WbeYaH e5KmvoEAaunDFFJFcZP/xkHLOw0IHhYSeyCdmbUL8UYVetEyVGKYjYOvP5XwMRADc88g yxPLxCxJ+p97LJUHDK4MZibRqkPAqQPn547pZED4d/b1XN/4A5/gQ2K1T5iecI5mp/x2 YIIzlkSDfnszfTA6IqmsOpH0TgLvDGVlpCGotExBvbS8u4G30KIiu9n6bD4OshRZvkrp 8GYvpVzbf1yAPJpLC8UortghAIG0GvgJYXbL/NEC3DBR3TieFyjK28mLWH374ebOCZ1T CywA==
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=jMsUGuppfDlOyXbgS73olb928sYiJavNJCOGm378cWc=; b=a3mWxZ3ZBsU17ePw9R3v88QNb3IRhyOlsZSxYhnaFVq1jctg+8BMmeihJrMiYasBgs av6w/EuJp4b4cFOEG0JfuPg8d8/VN2RK+iIjSLLlc9vr/cZ5ULBRnnmpCtf0cG+NmB2t kVOXXpq6fLfaQCq3rq5eWSJXnd+joE/AHbY+U29ud1CdluShDvkho7iWUzGE+lk+PLFL 94pjDHJOSWeAz2O5QUu3MX4e3wzkapqNXx/u2/KNcKO4MPaU5AHIFK4AijwNxkweKDXb gRGgHK1znrFtZbWknTGDdeRMaxhjV+w/Pyn2NtEtt+/on3z6IQNljOKOPEOr4QeIu0AX GqoA==
X-Gm-Message-State: AJaThX4/Dhsx6mRuinRZin8NdZK00iInzvBJSG8GZEcATeP3iwRSbda3 hcNPbBZBRuRCUm2EsVqCD0Hto4I4n3fqmXd7/gu02GQU
X-Google-Smtp-Source: AGs4zMa0Jncb15lOi3yo/iqdkVDPopi3uka1gDW+9V8Lvn0N4Vib/EwVJ0NIeRWEdkkffSGjGHVAzeCdNOd25/NlDx0=
X-Received: by 10.176.95.138 with SMTP id b10mr16018919uaj.55.1511284036320; Tue, 21 Nov 2017 09:07:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 09:06:55 -0800 (PST)
In-Reply-To: <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 09:06:55 -0800
Message-ID: 
To: Paul Kyzivat 
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="089e0822c7a023c413055e813cad"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 17:07:19 -0000

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

Paul said:

"When using lip sync, is there any necessity to put the language tag on the
video?"

[BA] Good point.

"   By including a language tag for spoken language in an audio
   description and using the "lip sync" grouping mechanism defined
   in [RFC5888] to group it with a video media stream it is possible
   to indicate synchronized audio and video so as to support lip
   reading."

[BA] This seems like an improvement.

On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat  wrote:

> On 11/21/17 10:59 AM, Bernard Aboba wrote:
>
>> [BA] LGTM.  Do you recall what the objection was to the term
>> "spoken/written language"?
>>
>> Gunnar had said:
>>
>> By including a language tag for spoken language in a video description
>> and using the "lip sync" grouping mechanism defined in [RFC5888] it is
>> possible to indicate synchronized audio and video so as to support lip
>> reading.
>>
>
> When using lip sync, is there any necessity to put the language tag on the
> video? ISTM that is irrelevant, as long as it is on the synced audio media.
> ISTM it would be better to say:
>
>    By including a language tag for spoken language in an audio
>    description and using the "lip sync" grouping mechanism defined
>    in [RFC5888] to group it with a video media stream it is possible
>    to indicate synchronized audio and video so as to support lip
>    reading.
>
>         Thanks,
>         Paul
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


Paul said:=C2=A0

"When using lip s=
ync, is there any necessity to put the language tag on the video?"

[BA] Good point.=C2=A0

"=
;=C2=A0 =C2=A0By including a language tag =
for spoken language in an audio
=C2=A0 =C2=A0description and using the "lip sync=
" grouping mechanism defined
=C2=A0 =C2=A0in [RFC5888] to group it with a video media stream it is pos=
sible
=C2=A0 =
=C2=A0to indicate synchronized audio and video so as to support lip
=C2=A0 =C2=A0re=
ading."

[BA] This seems like an improv=
ement.=C2=A0

On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat <=
pkyzivat@alum.mi=
t.edu> wrote:
On 11/21/17 10:59 AM, Bernard Aboba wrote:



[BA] LGTM.=C2=A0 Do you recall what the objection was to the term "spo=
ken/written language"?



Gunnar had said:



By including a language tag for spoken language in a video description and =
using the "lip sync" grouping mechanism defined in [RFC5888] it i=
s possible to indicate synchronized audio and video so as to support lip re=
ading. 





When using lip sync, is there any necessity to put the language tag on the =
video? ISTM that is irrelevant, as long as it is on the synced audio media.=
 ISTM it would be better to say:



=C2=A0 =C2=A0By including a language tag for spoken language in an audio

=C2=A0 =C2=A0description and using the "lip sync" grouping mechan=
ism defined

=C2=A0 =C2=A0in [RFC5888] to group it with a video media stream it is possi=
ble

=C2=A0 =C2=A0to indicate synchronized audio and video so as to support lip<=
br>
=C2=A0 =C2=A0reading.



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

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



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--089e0822c7a023c413055e813cad--


From nobody Tue Nov 21 11:45: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 5A1C9129572 for ; Tue, 21 Nov 2017 11:45:14 -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 P8PzSSv_0I24 for ; Tue, 21 Nov 2017 11:45:12 -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 CD35B129548 for ; Tue, 21 Nov 2017 11:45:11 -0800 (PST)
X-Halon-ID: 77c48d25-cef4-11e7-811c-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 77c48d25-cef4-11e7-811c-0050569116f7; Tue, 21 Nov 2017 20:45:04 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Tue, 21 Nov 2017 20:45:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------925C7BC7E725CFEBD00FA39B"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 19:45:14 -0000

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

Den 2017-11-21 kl. 18:06, skrev Bernard Aboba:
> Paul said:
>
> "When using lip sync, is there any necessity to put the language tag 
> on the video?"
>
> [BA] Good point.
>
> "   By including a language tag for spoken language in an audio
>    description and using the "lip sync" grouping mechanism defined
>    in [RFC5888] to group it with a video media stream it is possible
>    to indicate synchronized audio and video so as to support lip
>  reading."
>
> [BA] This seems like an improvement.
I do not think that an indication of lip reading synch grouping can 
be assumed to mean that the user promises to be seen in video. I guess 
that most products implementing the lip synch grouping do it generally 
for all calls regardless of if the user want to provide or see lips in 
synch. But it is a good feature to use if you desire to see a speaker.
The 'hlang' attribute in a video description is on the other hand clear 
indications that you want to provide or receive language in the video 
media stream.
Therefore I think we should return either to say that a spoken/written 
language tag in video media description means a view of the speaker if 
there is also a lip synch grouping, or even skip the dependency on lip 
synch grouping.  (there is a risk that we introduce tricky corner cases 
by the bundling of lip synch and language use. How about if we by 
further work agree on a way to indicate written captions in MPEG4 video, 
and want to indicate that in a product that always provides lip synch 
grouping. That will cause conflicts.)

Randall recently commented that use of text captions in the video stream 
is a far fetched use case. MPEG4 has caption elements defined and it can 
be provided in media declared as video, but it may be right that it is 
rarely or never used in conversational calls. If we can agree on that we 
could simply return to saying that a spoken/written language tag in 
video description means a view of a speaker, and skip the requirement to 
link it to the language in the audio stream.

Gunnar
>
> On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat  > wrote:
>
>     On 11/21/17 10:59 AM, Bernard Aboba wrote:
>
>         [BA] LGTM.  Do you recall what the objection was to the term
>         "spoken/written language"?
>
>         Gunnar had said:
>
>         By including a language tag for spoken language in a video
>         description and using the "lip sync" grouping mechanism
>         defined in [RFC5888] it is possible to indicate synchronized
>         audio and video so as to support lip reading.
>
>
>     When using lip sync, is there any necessity to put the language
>     tag on the video? ISTM that is irrelevant, as long as it is on the
>     synced audio media. ISTM it would be better to say:
>
>        By including a language tag for spoken language in an audio
>        description and using the "lip sync" grouping mechanism defined
>        in [RFC5888] to group it with a video media stream it is possible
>        to indicate synchronized audio and video so as to support lip
>        reading.
>
>             Thanks,
>             Paul
>
>
>     _______________________________________________
>     SLIM mailing list
>     SLIM@ietf.org 
>     https://www.ietf.org/mailman/listinfo/slim
>     
>
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------925C7BC7E725CFEBD00FA39B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2017-11-21 kl. 18:06, skrev Bernard Aboba:

    

      
Paul said: 
        


        

        
"When using lip sync, is there any necessity to put the
          language tag on the video?"

        


        

        
[BA] Good point. 

        


        

        
"   By including a language
            tag for spoken language in an audio

           description
          and using the "lip sync" grouping mechanism defined

           in [RFC5888] to group
          it with a video media stream it is possible

             to indicate synchronized audio and video so as to support
          lip

        
        
 
             reading."

        


        

        
[BA] This seems like an improvement. 

        

      

    

    <GH>I do not think that an indication of lip reading synch
    grouping can be assumed to mean that the user promises to be seen in
    video. I guess that most products implementing the lip synch
    grouping do it generally for all calls regardless of if the user
    want to provide or see lips in synch. But it is a good feature to
    use if you desire to see a speaker.

    The 'hlang' attribute in a video description is on the other hand
    clear indications that you want to provide or receive language in
    the video media stream. 

    Therefore I think we should return either to say that a
    spoken/written language tag in video media description means a view
    of the speaker if there is also a lip synch grouping, or even skip
    the dependency on lip synch grouping.  (there is a risk that we
    introduce tricky corner cases by the bundling of lip synch and
    language use. How about if we by further work agree on a way to
    indicate written captions in MPEG4 video, and want to indicate that
    in a product that always provides lip synch grouping. That will
    cause conflicts.) 

    

    Randall recently commented that use of text captions in the video
    stream is a far fetched use case. MPEG4 has caption elements defined
    and it can be provided in media declared as video, but it may be
    right that it is rarely or never used in conversational calls. If we
    can agree on that we could simply return to saying that a
    spoken/written language tag in video description means a view of a
    speaker, and skip the requirement to link it to the language in the
    audio stream. 

    

    Gunnar

    

      


        
On Tue, Nov 21, 2017 at 8:44 AM, Paul
          Kyzivat <pkyzivat@alum.mit.edu>
          wrote:

          
On 11/21/17 10:59 AM, Bernard Aboba wrote:

            
            

                [BA] LGTM.  Do you recall what the objection was to the
                term "spoken/written language"?

                

                Gunnar had said:

                

              
                By including a language tag for spoken language in a
                video description and using the "lip sync" grouping
                mechanism defined in [RFC5888] it is possible to
                indicate synchronized audio and video so as to support
                lip reading. 

              

            

            When using lip sync, is there any necessity to put the
            language tag on the video? ISTM that is irrelevant, as long
            as it is on the synced audio media. ISTM it would be better
            to say:

            

               By including a language tag for spoken language in an
            audio

                 description and using the "lip sync" grouping mechanism
              defined

            
               in [RFC5888] to group it with a video media stream it is
            possible

                 to indicate synchronized audio and video so as to
              support lip

                 reading.

              

            
                    Thanks,

                    Paul
            

              


                

                _______________________________________________

                SLIM mailing list

                SLIM@ietf.org

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

              

            

          

        

        

      

      

      

      

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


    

    

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

  


--------------925C7BC7E725CFEBD00FA39B--


From nobody Tue Nov 21 12:54:05 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 C918F129BCD for ; Tue, 21 Nov 2017 12:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OOulBsPVpyiW for ; Tue, 21 Nov 2017 12:54:03 -0800 (PST)
Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id C36451270AC for ; Tue, 21 Nov 2017 12:54:02 -0800 (PST)
X-AuditID: 1207440c-7fdff7000000143e-4c-5a14926893a5
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id EF.11.05182.862941A5; Tue, 21 Nov 2017 15:54:01 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vALKrwHs015304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Nov 2017 15:53:59 -0500
To: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>  
From: Paul Kyzivat 
Message-ID: <4efeeff4-bcd7-661e-93c9-23e6fec3704b@alum.mit.edu>
Date: Tue, 21 Nov 2017 15:53:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixO6iqJs5SSTKYP4mOYuZHzrZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0b48v2CRWsWqtmOsDYxXZbsYOTkkBEwkvr5dytTFyMUhJLCD SeLf1bOMEM5XJom2/YfYQaqEBYIkLk59xgZiiwgISnzvmQHVsZdN4siEz0wgCTYBLYk5h/6z gNi8AvYSfadWs4LYLAKqEk+nfABrFhVIk7gz4yETRI2gxMmZT8DqOQXsJC4fug5WwyxgJjFv 80NmCFtc4taT+UwQtrxE89bZzBMY+WchaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3W LU5OzMtLLdI11MvNLNFLTSndxAgJS54djN/WyRxiFOBgVOLhdUgQiRJiTSwrrsw9xCjJwaQk yitpChTiS8pPqcxILM6ILyrNSS0+xCjBwawkwuseA5TjTUmsrEotyodJSXOwKInzqi5R9xMS SE8sSc1OTS1ILYLJynBwKEnwVk4EahQsSk1PrUjLzClBSDNxcIIM5wEargJSw1tckJhbnJkO kT/FaMnR03PjDxPHoxt3geSzma8bmIVY8vLzUqXEeVlBGgRAGjJK8+BmwtLMK0ZxoBeFee9O AKriAaYouKmvgBYyAS38eVwYZGFJIkJKqoGRf+qfAw96/Z7lv50obx135vKiLWVxD3Vm8iaJ TzDcVpkVPGXHNIaUzF/1z+3Doy68qy3h2C615kp2lJzQIbtPlvpLZBX1sj7M2/alKkSsPH5l bITU4r7Xi/zu7C4wNBB7KfE+aXH8xLpngvcmLXrL/SuewW/ib+c3Fxyqnl9ie3zC8MvToLgk JZbijERDLeai4kQAioBayw4DAAA=
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 20:54:05 -0000

On 11/21/17 2:45 PM, Gunnar Hellström wrote:
> Den 2017-11-21 kl. 18:06, skrev Bernard Aboba:
>> Paul said:
>>
>> "When using lip sync, is there any necessity to put the language tag 
>> on the video?"
>>
>> [BA] Good point.
>>
>> "   By including a language tag for spoken language in an audio
>>    description and using the "lip sync" grouping mechanism defined
>>    in [RFC5888] to group it with a video media stream it is possible
>>    to indicate synchronized audio and video so as to support lip
>>  reading."
>>
>> [BA] This seems like an improvement.
> I do not think that an indication of lip reading synch grouping can 
> be assumed to mean that the user promises to be seen in video. I guess 
> that most products implementing the lip synch grouping do it generally 
> for all calls regardless of if the user want to provide or see lips in 
> synch.

I wonder if they do it even when it isn't true.

For instance, consider a movie that was created in English. So the 
actors are speaking English, the audio is labeled as English, and there 
is lip sync.

Now take the same movie and dub it in Spanish. Now the audio ought to be 
labeled as Spanish. But lip sync should no longer be indicated. Is that 
what happens in practice?

Of course, a totally deaf English speaking lip reader will understand 
both equally well. But there may not be anything in the signaling to 
indicate that he will have English lip motion.

The above isn't assuming that the content is being created explicitly to 
accommodate deaf people. If the goal is specifically to focus on that 
then some different policies might help.

	Thanks,
	Paul

> But it is a good feature to use if you desire to see a speaker.
> The 'hlang' attribute in a video description is on the other hand clear 
> indications that you want to provide or receive language in the video 
> media stream.
> Therefore I think we should return either to say that a spoken/written 
> language tag in video media description means a view of the speaker if 
> there is also a lip synch grouping, or even skip the dependency on lip 
> synch grouping.  (there is a risk that we introduce tricky corner cases 
> by the bundling of lip synch and language use. How about if we by 
> further work agree on a way to indicate written captions in MPEG4 video, 
> and want to indicate that in a product that always provides lip synch 
> grouping. That will cause conflicts.)
> 
> Randall recently commented that use of text captions in the video stream 
> is a far fetched use case. MPEG4 has caption elements defined and it can 
> be provided in media declared as video, but it may be right that it is 
> rarely or never used in conversational calls. If we can agree on that we 
> could simply return to saying that a spoken/written language tag in 
> video description means a view of a speaker, and skip the requirement to 
> link it to the language in the audio stream.
> 
> Gunnar
>>
>> On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat > > wrote:
>>
>>     On 11/21/17 10:59 AM, Bernard Aboba wrote:
>>
>>         [BA] LGTM.  Do you recall what the objection was to the term
>>         "spoken/written language"?
>>
>>         Gunnar had said:
>>
>>         By including a language tag for spoken language in a video
>>         description and using the "lip sync" grouping mechanism
>>         defined in [RFC5888] it is possible to indicate synchronized
>>         audio and video so as to support lip reading.
>>
>>
>>     When using lip sync, is there any necessity to put the language
>>     tag on the video? ISTM that is irrelevant, as long as it is on the
>>     synced audio media. ISTM it would be better to say:
>>
>>        By including a language tag for spoken language in an audio
>>        description and using the "lip sync" grouping mechanism defined
>>        in [RFC5888] to group it with a video media stream it is possible
>>        to indicate synchronized audio and video so as to support lip
>>        reading.
>>
>>             Thanks,
>>             Paul
>>
>>
>>     _______________________________________________
>>     SLIM mailing list
>>     SLIM@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/slim
>>     
>>
>>
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
> 
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
> 
> 
> 
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
> 


From nobody Tue Nov 21 13:07: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 379F4129BDA for ; Tue, 21 Nov 2017 13:07: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, 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 tG_pr1owInde for ; Tue, 21 Nov 2017 13:07:47 -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 CAF961270AC for ; Tue, 21 Nov 2017 13:07:46 -0800 (PST)
X-Halon-ID: fb749840-ceff-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id fb749840-ceff-11e7-96ae-005056917f90; Tue, 21 Nov 2017 22:07:29 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se> 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <21a8709d-87f1-e1e4-10cf-340e6b7e43ce@omnitor.se>
Date: Tue, 21 Nov 2017 22:07:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------65B0D4D6C0C82606FC8C0720"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 21:07:52 -0000

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

Den 2017-11-21 kl. 16:59, skrev Bernard Aboba:
> [BA] LGTM.  Do you recall what the objection was to the term 
> "spoken/written language"?
 It was in this mail in the archive:
https://www.ietf.org/mail-archive/web/slim/current/msg00744.html

It is Addison commenting on proposals for section 5.4, and specifically 
commenting on this proposed point:

>>>  2.    Text captions included in the video stream SHALL be indicated
>>> by a Language-Tag for spoken/written language.

And the comment from Addison was:

"I'm not sure what #2 really means. Shouldn't text captions be indicated by the written language
rather than the spoken language? And I'm not sure what "spoken/written language" means. "

My answer next day on this point was:

"
#2 was: "

2.    Text captions included in the video stream SHALL be indicated
by a Language-Tag for spoken/written language."

Yes, the intention is to use written language in the video stream. 
Thereare technologies for that.Since the language subtags in the IANA 
registry are combined for spokenlanguages and written languages, I call 
them Language-Tags forspoken/written language.It would be misleading to 
say that we use a Language-Tag for a writtenlanguage, because the same 
tag could in another context mean a spokenlanguage.Since we have the 
script subtag Zxxx for non-written, we do not need toconstruct an 
explicit tag for the written language tag, it should besufficient with 
our specification of the use in our case.In my latest recent proposal, I 
still have a very similar wording. Sinceyou had problems understanding 
it, there might still be a need to tuneit. Can you propose wording?This is the current
  proposal:

"   2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.
"
Addison responded in https://www.ietf.org/mail-archive/web/slim/current/msg00757.html

> Yes, the intention is to use written language in the video stream. There are
> technologies for that.

I'm aware of that. My concern is that in this case "spoken/written" is applied to "text captions", which are not spoken be definition? This section is talking about the differences between identifying spoken and written language. The text captions fall into the written side of the equation, no?

I'd probably prefer to see something like
"2. Text captions included in the video stream SHOULD include a Language-Tag to identify the language."

> Since the language subtags in the IANA registry are combined for spoken
> languages and written languages, I call them Language-Tags for spoken/written
> language.

The language subtags are for languages--all modalities. My comment here
is that "spoken/written" adds no information.

> It would be misleading to say that we use a Language-Tag for a written
> language, because the same tag could in another context mean a spoken
> language.

One uses a Language-Tag for indicating the language. When the text is written,
sometimes the user will pick a different language tag (zh-Hant-HK) than they
might choose for spoken text (yue-HK, zh-cmn-HK, etc.). Sometimes (actually,
nearly all the time except for special cases) the language tag for the spoken
and written language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the
modality of the language is a separate consideration from the language.
Nearly always, it is better to use the same tag for both spoken and written
content rather than trying to use the tag to distinguish between them:
different Content-Types require different decoders anyway, but it is really
useful to say "give me all of the 'en-US' content you have" or "do you have
  content for a user who speaks 'es'"

 The result was that we modified text in a few places where we had used
"spoken/written language tag".

Now, the term has reappeared, and I assume that the language experts still
have the same concerns as in February.

When we use the term, it is intended to mean "tag for non-signed language".
Therefore it is not appropriate to just replace it with "Language tag"
and we need to decide what to do. Shall we define what we mean with
"spoken/written language tag" or try to reword the sentences containing that term?
  


Gunnar

>
> Gunnar had said:
>
> "A proposal trying to act on issues 1-4 plus other minor rewording:
>  ---------------------------------------------------------------------------------------------------------------
> 5.4 Media, Language and Modality indications
> A spoken/written language tag included in a text media description is 
> an indication for written language. A spoken/written language tag 
> included in an audio media description is an indication for spoken 
> language. A sign language tag included in a video media description is 
> an indication for sign language in the video stream.
>
> A sign language can be identified by the existence in the IANA 
> registry of language subtags according to BCP 47 [RFC5646] of the 
> language subtag with the Type field "extlang" combined with the Prefix 
> field value "sgn". A spoken/written language tag can be identified by 
> not having any such "sgn" prefix.
>
> This document does not define the use of sign language tags in text or 
> audio media.  By including a language tag for spoken language in a 
> video description and using the "lip sync" grouping mechanism defined 
> in [RFC5888] it is possible to indicate synchronized audio and video 
> so as to support lip reading. Other use of spoken/written language 
> tags in a video description (such as for video embedded text captions) 
> is not defined in this document.
>
> Use of 'hlang' attributes may appear in other media descriptions, such 
> as "message" and "application" supported by further work or 
> application specific agreements."
>
> On Tue, Nov 21, 2017 at 12:00 AM, Gunnar Hellström 
> > wrote:
>
>     Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
>>     Can we include text from Brian's suggestion? For example:
>>
>>     "If a sign language is signaled in a video stream, it is
>>     interpreted as an indication that sign language will appear in
>>     the video. A sign language can be identified by the existence in
>>     the IANA registry of language subtags according to BCP 47
>>     [RFC5646] of the language subtag with the Type field "extlang"
>>     combined with the Prefix field value "sgn". A spoken/written
>>     language tag can be identified by not having any such "sgn"
>>     prefix. This document does not define any other use for language
>>     tags in video media (such as how to indicate a desire for visible
>>     captions).
>>
>>     This document does not define the use of sign language tags in
>>     text or audio media. If a spoken/written language tag is included
>>     in text media, it indicates a desire for written language. If a
>>     spoken/written language tag is included in audio media, it is
>>     interpreted as an indication that spoken language is desired. 
>>     Using the "lip sync" grouping mechanism defined in [RFC5888], it
>>     is possible to indicate the desire to synchronize audio and video
>>     so as to support lip reading.
>>
>>     Use of language tags may appear in other media, such as "message"
>>     and "application".  Such use may be supported by further work or
>>     application specific agreement."
>     Quite good. I see four small issues.
>     1: "WILL appear" is not right in the first sentence. The
>     indication may be just one of a set of indicated languages.
>     2: The first paragraph says that we do not define other use of
>     language tags in video than for sign language, but the second
>     paragraph defines how to use tags for spoken language in video.
>     3: I prefer to start with the three normal clearly supported cases.
>     4: The indications sometimes indicate desire, sometimes
>     capability. Therefore the word "desire" is not suitable in the
>     explanations.
>     5: In the LC review, we had some resistance against using the term
>     "spoken/written language tag". It appears again in the proposal. I
>     do not understand the resistance and I do not know how strict it
>     was, but we need to know if it is ok to use that term.  (I do not
>     change that for now in the proposal below.)
>
>
>     A proposal trying to act on issues 1-4 plus other minor rewording:
>      ---------------------------------------------------------------------------------------------------------------
>     5.4 Media, Language and Modality indications
>     A spoken/written language tag included in a text media description
>     is an indication for written language. A spoken/written language
>     tag included in an audio media description is an indication for
>     spoken language. A sign language tag included in a video media
>     description is an indication for sign language in the video stream.
>
>     A sign language can be identified by the existence in the IANA
>     registry of language subtags according to BCP 47 [RFC5646] of the
>     language subtag with the Type field "extlang" combined with the
>     Prefix field value "sgn". A spoken/written language tag can be
>     identified by not having any such "sgn" prefix.
>
>     This document does not define the use of sign language tags in
>     text or audio media.  By including a language tag for spoken
>     language in a video description and using the "lip sync" grouping
>     mechanism defined in [RFC5888] it is possible to indicate
>     synchronized audio and video so as to support lip reading. Other
>     use of spoken/written language tags in a video description (such
>     as for video embedded text captions) is not defined in this document.
>
>     Use of 'hlang' attributes may appear in other media descriptions,
>     such as "message" and "application" supported by further work or
>     application specific agreements.
>
>     ------------------------------------------------------------------
>
>
>>
>>
>>
>>     On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellström
>>     >     > wrote:
>>
>>         A new proposal for new text taking in latest discussion of
>>         Bernard, Paul and Brian:
>>
>>         -----Old text----
>>
>>
>>               5.4 Undefined Combinations
>>
>>         The behavior when specifying a non-signed language tag for a
>>         video media stream, or a signed language tag for an audio or
>>         text media stream, is not defined in this document. The
>>         problem of knowing which language tags are signed and which
>>         are not is out of scope of this document.
>>
>>         -----New text------------
>>         5.4 Media, Language and Modality indications
>>
>>         The combination of Language tags and other information in the
>>         media descriptions shall be composed so that the intended
>>         modality can be concluded by the negotiating parties. The
>>         following combinations of language tags and media provide
>>         obvious information about the modality: sign language tags in
>>         video media indicate signed modality, language tags in audio
>>         media indicate spoken modality and language tags in text
>>         media indicate written modality. The examples in this
>>         specification are all from this set of three obvious
>>         language/media/modality combinations.
>>
>>         A sign language can be identified by the existence in the
>>         IANA registry of language subtags according to BCP 47
>>         [RFC5646] of the language subtag with the Type field
>>         "extlang" combined with the Prefix field value "sgn".
>>         A specific spoken or written language can be identified by
>>         not having any such "sgn" Prefix.
>>
>>         Use of language may appear in other media, such as "message"
>>         and "application". Video media may be used for other
>>         modalities than signed, e.g. a view of a speaker or text
>>         captions. Such use may be supported by further work or
>>         application specific agreements for evaluation of the
>>         intended modality.
>>
>>         ---------------------------End of new
>>         text---------------------------------------
>>
>>
>>         Den 2017-11-20 kl. 21:44, skrev Gunnar Hellström:
>>>         Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>>>>         Gunnar said:
>>>>
>>>>         "5.4 Media, Language and Modality indications
>>>>
>>>>         The combination of Language tags and other information in
>>>>         the media descriptions should be composed so that the
>>>>         intended modality can be concluded by the negotiating
>>>>         parties. "
>>>>
>>>>         [BA] Is the "should" intended to be normative?
>>>         You are right that SHOULD should be avoided and it would
>>>         be better to say MUST if we can. But I can imagine limited
>>>         area applications having application agreements e.g. saying
>>>         that a non-signed language tag in video media means a view
>>>         of a talking person.   The negotiating applications know
>>>         about this agreement so they can make the conclusion. So, if
>>>         such situations can be included in how the parties make
>>>         their conclusions, we can change to MUST.
>>>>
>>>>         The following combinations of language tags and media
>>>>         provide obvious information about the modality: sign
>>>>         language tags in video media indicate signed modality... A
>>>>         sign language can be identified by the existence in the
>>>>         IANA registry of language subtags according to BCP 47
>>>>         [RFC5646] of the language subtag with the Type field
>>>>         "extlang" combined with the Prefix field value "sgn". A
>>>>         specific spoken or written language can be identified by
>>>>         not having any such "sgn" Prefix.
>>>>
>>>>         Use of language may appear in other media, such as
>>>>         "message" and "application". Video media may be used for
>>>>         other modalities than signed. Such use may be supported by
>>>>         further work or application specific agreements or
>>>>         indications for evaluation of the intended modality."
>>>>
>>>>         [BA] Assume we can confirm the mechanism for distinguishing
>>>>         signed/non-signed languages, this part seems relatively solid.
>>>>
>>>>         spoken language tags for audio media indicate spoken
>>>>         modality and written language tags for text media indicate
>>>>         written modality. The examples in this specification are
>>>>         all from this set of three obvious language/media/modality
>>>>         combinations.
>>>>
>>>>         [BA]  This is where the ground gets less solid - we don't
>>>>         really have a general mechanism for distinguishing spoken
>>>>         and written modality among non-signed languages. Perhaps we
>>>>         should just say "language tags in audio media indicate
>>>>         spoken modality and language tags in text media indicate
>>>>         written modality".
>>>         Yes, right, that is better wording.
>>>
>>>         Gunnar
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström
>>>>         >>>         > wrote:
>>>>
>>>>             It is not the signed languages that are causing the
>>>>             problem. It is the spoken and written, when used in
>>>>             other media than the obvious audio and text media.
>>>>
>>>>             And we should specify what is obvious and well defined
>>>>             and not, so here is a new shorter proposal for section 5.4.
>>>>
>>>>             -----Old text----
>>>>
>>>>
>>>>                   5.4 Undefined Combinations
>>>>
>>>>             The behavior when specifying a non-signed language tag
>>>>             for a video media stream, or a signed language tag for
>>>>             an audio or text media stream, is not defined in this
>>>>             document. The problem of knowing which language tags
>>>>             are signed and which are not is out of scope of this
>>>>             document.
>>>>
>>>>             -----New text------------
>>>>             5.4 Media, Language and Modality indications
>>>>
>>>>             The combination of Language tags and other information
>>>>             in the media descriptions should be composed so that
>>>>             the intended modality can be concluded by the
>>>>             negotiating parties. The following combinations of
>>>>             language tags and media provide obvious information
>>>>             about the modality: sign language tags in video media
>>>>             indicate signed modality, spoken language tags for
>>>>             audio media indicate spoken modality and written
>>>>             language tags for text media indicate written modality.
>>>>             The examples in this specification are all from this
>>>>             set of three obvious language/media/modality combinations.
>>>>
>>>>             A sign language can be identified by the existence in
>>>>             the IANA registry of language subtags according to BCP
>>>>             47 [RFC5646] of the language subtag with the Type field
>>>>             "extlang" combined with the Prefix field value "sgn".
>>>>             A specific spoken or written language can be identified
>>>>             by not having any such "sgn" Prefix.
>>>>
>>>>             Use of language may appear in other media, such as
>>>>             "message" and "application". Video media may be used
>>>>             for other modalities than signed. Such use may be
>>>>             supported by further work or application specific
>>>>             agreements or indications for evaluation of the
>>>>             intended modality.
>>>>
>>>>             -------------------------------------------------------------------End
>>>>             of new text---------------------------------------
>>>>
>>>>             Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>>>>             At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>>>
>>>>>>              "So let's delete Section 5.4 and be done with it. 
>>>>>>             Neither of the statements is necessary."
>>>>>>
>>>>>>              [BA]  I agree that Section 5.4 does not add much
>>>>>>             value as it stands.
>>>>>>
>>>>>>              "Non-signed" is not used outside of Section 5.4, so
>>>>>>             there would not appear to be a need to define it if
>>>>>>             Section 5.4 were to be deleted.
>>>>>>
>>>>>>              However, the term "signed" is used in 7 other places
>>>>>>             in the document other than in Section 5.4.
>>>>>
>>>>>             But none of those instances are normative.
>>>>>
>>>>>>              So we may need to find a reference to define that term.
>>>>>
>>>>>             Because the uses of the term are descriptive and
>>>>>             mostly background, I do not think we need to add a
>>>>>             definition or even a reference to a definition of the
>>>>>             term.
>>>>>
>>>>>             --Randall
>>>>>
>>>>>>
>>>>>>              If Gunnar's suggested definition can be confirmed,
>>>>>>             this might be as simple as adding a reference to the
>>>>>>             IANA language tag repository.
>>>>>>
>>>>>>              On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
>>>>>>             <
>>>>>>             rg+ietf@randy.pensive.org
>>>>>>             > wrote:
>>>>>>
>>>>>>              My view of issue #43 remains that we do not need to
>>>>>>             specify a mechanism for determining which tags are
>>>>>>             signed.  In the email discussion of the past month or
>>>>>>             so, I fear we are drifting into adding complexity
>>>>>>             rather than removing it.  I think the way forward is
>>>>>>             to keep this document as simple as possible. As
>>>>>>             Bernard notes in his email of 10/23, there is no
>>>>>>             benefit in this case of explicitly saying that
>>>>>>             certain things are not defined. Since the document
>>>>>>             does not define them, they are undefined in the
>>>>>>             document.
>>>>>>
>>>>>>              At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>>>>
>>>>>>               In other words,it is not clear to me how Section
>>>>>>             5.4's discussion of scope improves or clarifies the
>>>>>>             situation in any way - and there is some possibility
>>>>>>             that it could cause problems.
>>>>>>
>>>>>>
>>>>>>
>>>>>>              I believe comment #43 should be closed as no longer
>>>>>>             applicable, since the text against which it was
>>>>>>             generated has been deleted. (I've said this before,
>>>>>>             and I believe it remains the case.)
>>>>>>
>>>>>>              The comment from which #43 derives was made against
>>>>>>             a version of the document that had text explicitly
>>>>>>             discussing signed versus unsigned tags.  That text
>>>>>>             was subsequently deleted.
>>>>>>
>>>>>>              Here is the comment from which #43 derived:
>>>>>>
>>>>>>                  5.2.  New 'humintlang-send' and
>>>>>>             'humintlang-recv' attributes
>>>>>>
>>>>>>                  Note that while signed language tags are used
>>>>>>             with a video stream
>>>>>>               to
>>>>>>                  indicate sign language, a spoken language tag
>>>>>>             for a video stream
>>>>>>               in
>>>>>>                  parallel with an audio stream with the same
>>>>>>             spoken language tag
>>>>>>                  indicates a request for a supplemental video
>>>>>>             stream to see the
>>>>>>                  speaker.
>>>>>>
>>>>>>               And there's a similar paragraph in 5.4:
>>>>>>
>>>>>>                  A spoken language tag for a video stream in
>>>>>>             conjunction with an
>>>>>>
>>>>>>               audio
>>>>>>
>>>>>>                  stream with the same language might indicate a
>>>>>>             request for
>>>>>>                  supplemental video to see the speaker.
>>>>>>
>>>>>>
>>>>>>               I think this mechanism needs to be described more
>>>>>>             exactly, and in
>>>>>>               particular, it should not depend on the UA
>>>>>>             understanding which
>>>>>>               language tags are spoken language tags.  It seems
>>>>>>             to me that a
>>>>>>               workable rule is that there is an audio stream and
>>>>>>             a video stream and
>>>>>>               they specify exactly the same language tag in their
>>>>>>             respective
>>>>>>               humintlang attributes.  In that case, it is a
>>>>>>             request for a spoken
>>>>>>               language with simultaneous video of the speaker,
>>>>>>             and those requests
>>>>>>               should be considered satisfied only if both streams
>>>>>>             can be
>>>>>>               established.
>>>>>>
>>>>>>
>>>>>>              The offending text that was in 5.2 and 5.4 was deleted.
>>>>>>
>>>>>>              The only remaining text that even mentions the issue
>>>>>>             is Section 5.4:
>>>>>>
>>>>>>                 The behavior when specifying a non-signed
>>>>>>             language tag for a video
>>>>>>                 media stream, or a signed language tag for an
>>>>>>             audio or text media
>>>>>>                 stream, is not defined in this document.
>>>>>>
>>>>>>                 The problem of knowing which language tags are
>>>>>>             signed and which are
>>>>>>                 not is out of scope of this document.
>>>>>>
>>>>>>              So, let's delete Section 5.4 and be done with it.
>>>>>>             Neither of the statements is necessary.
>>>>>>
>>>>>>              --
>>>>>>              Randall Gellens
>>>>>>              Opinions are personal;    facts are suspect;    I
>>>>>>             speak for myself only
>>>>>>              -------------- Randomly selected tag: ---------------
>>>>>>              Make it right before you make it faster.
>>>>>
>>>>>
>>>>
>>>>             -- ----------------------------------------- Gunnar
>>>>             Hellström Omnitor gunnar.hellstrom@omnitor.se
>>>>              +46 708 204 288
>>>>
>>>>
>>>
>>>         -- 
>>>         -----------------------------------------
>>>         Gunnar Hellström
>>>         Omnitor
>>>         gunnar.hellstrom@omnitor.se 
>>>         +46 708 204 288
>>>
>>>
>>>         _______________________________________________
>>>         SLIM mailing list
>>>         SLIM@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/slim
>>>         
>>
>>         -- 
>>         -----------------------------------------
>>         Gunnar Hellström
>>         Omnitor
>>         gunnar.hellstrom@omnitor.se 
>>         +46 708 204 288
>>
>>
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     gunnar.hellstrom@omnitor.se 
>     +46 708 204 288
>
>

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


--------------65B0D4D6C0C82606FC8C0720
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k
eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICBEZW4gMjAxNy0xMS0y
MSBrbC4gMTY6NTksIHNrcmV2IEJlcm5hcmQgQWJvYmE6PGJyPg0KICAgIDxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiDQpjaXRlPSJtaWQ6Q0FPVysyZHNyUm9DRTRZUTFVK3k0NDhDNHFtTVkx
SGIrOGpNPWFUeXp2c1BCWUEwYWtnQG1haWwuZ21haWwuY29tIj4NCiAgICAgIDxkaXYgZGly
PSJsdHIiPltCQV0gTEdUTS7CoCBEbyB5b3UgcmVjYWxsIHdoYXQgdGhlIG9iamVjdGlvbiB3
YXMgdG8NCiAgICAgICAgdGhlIHRlcm0gInNwb2tlbi93cml0dGVuIGxhbmd1YWdlIj88L2Rp
dj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgJmx0O0dIJmd0OyBJdCB3YXMgaW4gdGhpcyBt
YWlsIGluIHRoZSBhcmNoaXZlOjxicj4NCiAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZy
ZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Ns
aW0vY3VycmVudC9tc2cwMDc0NC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc0NC5odG1sPC9hPjxicj4NCiAgICA8YnI+
DQogICAgSXQgaXMgQWRkaXNvbiBjb21tZW50aW5nIG9uIHByb3Bvc2FscyBmb3Igc2VjdGlv
biA1LjQsIGFuZA0KICAgIHNwZWNpZmljYWxseSBjb21tZW50aW5nIG9uIHRoaXMgcHJvcG9z
ZWQgcG9pbnQ6PGJyPg0KICAgIDxicj4NCiAgICA8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAs
IDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6IDI7IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj
b3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFs
OyI+Jmd0OyZndDsmZ3Q7ICAyLiAgICBUZXh0IGNhcHRpb25zIGluY2x1ZGVkIGluIHRoZSB2
aWRlbyBzdHJlYW0gU0hBTEwgYmUgaW5kaWNhdGVkDQomZ3Q7Jmd0OyZndDsgYnkgYSBMYW5n
dWFnZS1UYWcgZm9yIHNwb2tlbi93cml0dGVuIGxhbmd1YWdlLg0KDQombHQ7R0gmZ3Q7QW5k
IHRoZSBjb21tZW50IGZyb20gQWRkaXNvbiB3YXM6DQoNCiJJJ20gbm90IHN1cmUgd2hhdCAj
MiByZWFsbHkgbWVhbnMuIFNob3VsZG4ndCB0ZXh0IGNhcHRpb25zIGJlIGluZGljYXRlZCBi
eSB0aGUgd3JpdHRlbiBsYW5ndWFnZSANCnJhdGhlciB0aGFuIHRoZSBzcG9rZW4gbGFuZ3Vh
Z2U/IEFuZCBJJ20gbm90IHN1cmUgd2hhdCAic3Bva2VuL3dyaXR0ZW4gbGFuZ3VhZ2UiIG1l
YW5zLiAiDQoNCiZsdDtHSCZndDtNeSBhbnN3ZXIgbmV4dCBkYXkgb24gdGhpcyBwb2ludCB3
YXM6DQoNCiINCiMyIHdhczogIg0KDQoyLiAgICBUZXh0IGNhcHRpb25zIGluY2x1ZGVkIGlu
IHRoZSB2aWRlbyBzdHJlYW0gU0hBTEwgYmUgaW5kaWNhdGVkDQpieSBhIExhbmd1YWdlLVRh
ZyBmb3Igc3Bva2VuL3dyaXR0ZW4gbGFuZ3VhZ2UuIg0KDQo8dHQgc3R5bGU9ImNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJl
czogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAw
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFy
dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl
OiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0
LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7Ij5ZZXMsIHRoZSBpbnRlbnRpb24gaXMgdG8g
dXNlIHdyaXR0ZW4gbGFuZ3VhZ2UgaW4gdGhlIHZpZGVvIHN0cmVhbS4gVGhlcmU8c3Bhbj7C
oDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0
LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5p
dGlhbDsiPmFyZSB0ZWNobm9sb2dpZXMgZm9yIHRoYXQuPHNwYW4+wqA8L3NwYW4+PC90dD48
dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAy
OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uLXN0
eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7Ij5TaW5jZSB0
aGUgbGFuZ3VhZ2Ugc3VidGFncyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcmUgY29tYmluZWQg
Zm9yIHNwb2tlbjxzcGFuPsKgPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAs
IDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4dC1kZWNv
cmF0aW9uLWNvbG9yOiBpbml0aWFsOyI+bGFuZ3VhZ2VzIGFuZCB3cml0dGVuIGxhbmd1YWdl
cywgSSBjYWxsIHRoZW0gTGFuZ3VhZ2UtVGFncyBmb3I8c3Bhbj7CoDwvc3Bhbj48L3R0Pjx0
dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24tc3R5
bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPnNwb2tlbi93
cml0dGVuIGxhbmd1YWdlLjxzcGFuPsKgPC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJjb2xvcjog
cmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVy
ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQw
MDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogc3Rh
cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj
ZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4
dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsOyI+SXQgd291bGQgYmUgbWlzbGVhZGluZyB0
byBzYXkgdGhhdCB3ZSB1c2UgYSBMYW5ndWFnZS1UYWcgZm9yIGEgd3JpdHRlbjwvdHQ+PHR0
IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbi1zdHls
ZTogaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsOyI+bGFuZ3VhZ2Us
IGJlY2F1c2UgdGhlIHNhbWUgdGFnIGNvdWxkIGluIGFub3RoZXIgY29udGV4dCBtZWFuIGEg
c3Bva2VuPHNwYW4+wqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg
MCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRp
b24tY29sb3I6IGluaXRpYWw7Ij5sYW5ndWFnZS48c3Bhbj7CoDwvc3Bhbj48L3R0Pjx0dCBz
dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh
cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRl
eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6
IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPlNpbmNlIHdlIGhh
dmUgdGhlIHNjcmlwdCBzdWJ0YWcgWnh4eCBmb3Igbm9uLXdyaXR0ZW4sIHdlIGRvIG5vdCBu
ZWVkIHRvPHNwYW4+wqA8L3NwYW4+PC90dD48dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg
MCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRp
b24tY29sb3I6IGluaXRpYWw7Ij5jb25zdHJ1Y3QgYW4gZXhwbGljaXQgdGFnIGZvciB0aGUg
d3JpdHRlbiBsYW5ndWFnZSB0YWcsIGl0IHNob3VsZCBiZTxzcGFuPsKgPC9zcGFuPjwvdHQ+
PHR0IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog
MjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzog
MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbi1z
dHlsZTogaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsOyI+c3VmZmlj
aWVudCB3aXRoIG91ciBzcGVjaWZpY2F0aW9uIG9mIHRoZSB1c2UgaW4gb3VyIGNhc2UuPC90
dD48dHQgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsg
Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z
OiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u
LXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7Ij5JbiBt
eSBsYXRlc3QgcmVjZW50IHByb3Bvc2FsLCBJIHN0aWxsIGhhdmUgYSB2ZXJ5IHNpbWlsYXIg
d29yZGluZy4gU2luY2U8c3Bhbj7CoDwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVz
OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQt
ZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPnlvdSBoYWQgcHJvYmxlbXMgdW5kZXJzdGFu
ZGluZyBpdCwgdGhlcmUgbWlnaHQgc3RpbGwgYmUgYSBuZWVkIHRvIHR1bmU8c3Bhbj7CoDwv
c3Bhbj48L3R0Pjx0dCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTog
bm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j
YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3Jk
LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl
Y29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlh
bDsiPml0LiBDYW4geW91IHByb3Bvc2Ugd29yZGluZz88L3R0PlRoaXMgaXMgdGhlIGN1cnJl
bnQNCsKgcHJvcG9zYWw6DQoNCiIgICAyLiAgICBUZXh0IGNhcHRpb25zIGluY2x1ZGVkIGlu
IHRoZSB2aWRlbyBzdHJlYW0gU0hPVUxEIGJlIGluZGljYXRlZA0KICBieSBhIGh1bWludGxh
bmcgYXR0cmlidXRlIHdpdGggTGFuZ3VhZ2UtVGFnIGZvciBzcG9rZW4vd3JpdHRlbiBsYW5n
dWFnZS4NCiINCiZsdDtHSCZndDtBZGRpc29uIHJlc3BvbmRlZCBpbiA8YSBjbGFzcz0ibW96
LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc1Ny5odG1sIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NsaW0vY3VycmVudC9tc2cwMDc1Ny5odG1sPC9hPg0K
DQomZ3Q7IFllcywgdGhlIGludGVudGlvbiBpcyB0byB1c2Ugd3JpdHRlbiBsYW5ndWFnZSBp
biB0aGUgdmlkZW8gc3RyZWFtLiBUaGVyZSBhcmUNCiZndDsgdGVjaG5vbG9naWVzIGZvciB0
aGF0Lg0KDQpJJ20gYXdhcmUgb2YgdGhhdC4gTXkgY29uY2VybiBpcyB0aGF0IGluIHRoaXMg
Y2FzZSAic3Bva2VuL3dyaXR0ZW4iIGlzIGFwcGxpZWQgdG8gInRleHQgY2FwdGlvbnMiLCB3
aGljaCBhcmUgbm90IHNwb2tlbiBiZSBkZWZpbml0aW9uPyBUaGlzIHNlY3Rpb24gaXMgdGFs
a2luZyBhYm91dCB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiBpZGVudGlmeWluZyBzcG9rZW4g
YW5kIHdyaXR0ZW4gbGFuZ3VhZ2UuIFRoZSB0ZXh0IGNhcHRpb25zIGZhbGwgaW50byB0aGUg
d3JpdHRlbiBzaWRlIG9mIHRoZSBlcXVhdGlvbiwgbm8/DQoNCkknZCBwcm9iYWJseSBwcmVm
ZXIgdG8gc2VlIHNvbWV0aGluZyBsaWtlIA0KIjIuIFRleHQgY2FwdGlvbnMgaW5jbHVkZWQg
aW4gdGhlIHZpZGVvIHN0cmVhbSBTSE9VTEQgaW5jbHVkZSBhIExhbmd1YWdlLVRhZyB0byBp
ZGVudGlmeSB0aGUgbGFuZ3VhZ2UuIg0KDQomZ3Q7IFNpbmNlIHRoZSBsYW5ndWFnZSBzdWJ0
YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFyZSBjb21iaW5lZCBmb3Igc3Bva2VuDQomZ3Q7
IGxhbmd1YWdlcyBhbmQgd3JpdHRlbiBsYW5ndWFnZXMsIEkgY2FsbCB0aGVtIExhbmd1YWdl
LVRhZ3MgZm9yIHNwb2tlbi93cml0dGVuDQomZ3Q7IGxhbmd1YWdlLg0KDQpUaGUgbGFuZ3Vh
Z2Ugc3VidGFncyBhcmUgZm9yIGxhbmd1YWdlcy0tYWxsIG1vZGFsaXRpZXMuIE15IGNvbW1l
bnQgaGVyZSANCmlzIHRoYXQgInNwb2tlbi93cml0dGVuIiBhZGRzIG5vIGluZm9ybWF0aW9u
Lg0KDQomZ3Q7IEl0IHdvdWxkIGJlIG1pc2xlYWRpbmcgdG8gc2F5IHRoYXQgd2UgdXNlIGEg
TGFuZ3VhZ2UtVGFnIGZvciBhIHdyaXR0ZW4NCiZndDsgbGFuZ3VhZ2UsIGJlY2F1c2UgdGhl
IHNhbWUgdGFnIGNvdWxkIGluIGFub3RoZXIgY29udGV4dCBtZWFuIGEgc3Bva2VuDQomZ3Q7
IGxhbmd1YWdlLg0KDQpPbmUgdXNlcyBhIExhbmd1YWdlLVRhZyBmb3IgaW5kaWNhdGluZyB0
aGUgbGFuZ3VhZ2UuIFdoZW4gdGhlIHRleHQgaXMgd3JpdHRlbiwgDQpzb21ldGltZXMgdGhl
IHVzZXIgd2lsbCBwaWNrIGEgZGlmZmVyZW50IGxhbmd1YWdlIHRhZyAoemgtSGFudC1ISykg
dGhhbiB0aGV5IA0KbWlnaHQgY2hvb3NlIGZvciBzcG9rZW4gdGV4dCAoeXVlLUhLLCB6aC1j
bW4tSEssIGV0Yy4pLiBTb21ldGltZXMgKGFjdHVhbGx5LCANCm5lYXJseSBhbGwgdGhlIHRp
bWUgZXhjZXB0IGZvciBzcGVjaWFsIGNhc2VzKSB0aGUgbGFuZ3VhZ2UgdGFnIGZvciB0aGUg
c3Bva2VuIA0KYW5kIHdyaXR0ZW4gbGFuZ3VhZ2UgaXMgdGhlIHNhbWUgdGFnIChlbi1VUywg
ZGUtQ0gsIGphLUpQLCBldGMuKS4gQWdhaW4sIHRoZSANCm1vZGFsaXR5IG9mIHRoZSBsYW5n
dWFnZSBpcyBhIHNlcGFyYXRlIGNvbnNpZGVyYXRpb24gZnJvbSB0aGUgbGFuZ3VhZ2UuIA0K
TmVhcmx5IGFsd2F5cywgaXQgaXMgYmV0dGVyIHRvIHVzZSB0aGUgc2FtZSB0YWcgZm9yIGJv
dGggc3Bva2VuIGFuZCB3cml0dGVuIA0KY29udGVudCByYXRoZXIgdGhhbiB0cnlpbmcgdG8g
dXNlIHRoZSB0YWcgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGVtOiANCmRpZmZlcmVudCBD
b250ZW50LVR5cGVzIHJlcXVpcmUgZGlmZmVyZW50IGRlY29kZXJzIGFueXdheSwgYnV0IGl0
IGlzIHJlYWxseSANCnVzZWZ1bCB0byBzYXkgImdpdmUgbWUgYWxsIG9mIHRoZSAnZW4tVVMn
IGNvbnRlbnQgeW91IGhhdmUiIG9yICJkbyB5b3UgaGF2ZQ0KwqBjb250ZW50IGZvciBhIHVz
ZXIgd2hvIHNwZWFrcyAnZXMnIg0KDQombHQ7R0gmZ3Q7IFRoZSByZXN1bHQgd2FzIHRoYXQg
d2UgbW9kaWZpZWQgdGV4dCBpbiBhIGZldyBwbGFjZXMgd2hlcmUgd2UgaGFkIHVzZWQgDQoi
c3Bva2VuL3dyaXR0ZW4gbGFuZ3VhZ2UgdGFnIi4gDQoNCk5vdywgdGhlIHRlcm0gaGFzIHJl
YXBwZWFyZWQsIGFuZCBJIGFzc3VtZSB0aGF0IHRoZSBsYW5ndWFnZSBleHBlcnRzIHN0aWxs
IA0KaGF2ZSB0aGUgc2FtZSBjb25jZXJucyBhcyBpbiBGZWJydWFyeS4gDQoNCldoZW4gd2Ug
dXNlIHRoZSB0ZXJtLCBpdCBpcyBpbnRlbmRlZCB0byBtZWFuICJ0YWcgZm9yIG5vbi1zaWdu
ZWQgbGFuZ3VhZ2UiLg0KVGhlcmVmb3JlIGl0IGlzIG5vdCBhcHByb3ByaWF0ZSB0byBqdXN0
IHJlcGxhY2UgaXQgd2l0aCAiTGFuZ3VhZ2UgdGFnIg0KYW5kIHdlIG5lZWQgdG8gZGVjaWRl
IHdoYXQgdG8gZG8uIFNoYWxsIHdlIGRlZmluZSB3aGF0IHdlIG1lYW4gd2l0aCANCiJzcG9r
ZW4vd3JpdHRlbiBsYW5ndWFnZSB0YWciIG9yIHRyeSB0byByZXdvcmQgdGhlIHNlbnRlbmNl
cyBjb250YWluaW5nIHRoYXQgdGVybT8NCiANCg0KDQpHdW5uYXINCjwvcHJlPg0KICAgIDxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiDQpjaXRlPSJtaWQ6Q0FPVysyZHNyUm9DRTRZUTFVK3k0
NDhDNHFtTVkxSGIrOGpNPWFUeXp2c1BCWUEwYWtnQG1haWwuZ21haWwuY29tIj4NCiAgICAg
IDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQog
ICAgICAgIDxkaXY+R3VubmFyIGhhZCBzYWlkOsKgDQogICAgICAgICAgPGRpdj48YnI+DQog
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj4iPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi44cHgiPkEgcHJvcG9zYWwgdHJ5aW5nIHRvIGFjdA0KICAgICAgICAgICAgICBvbiBp
c3N1ZXMgMS00IHBsdXMgb3RoZXIgbWlub3IgcmV3b3JkaW5nOjwvc3Bhbj48L2Rpdj4NCiAg
ICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+wqAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48d2JyDQogICAgICAgICAgICBzdHlsZT0iZm9udC1z
aXplOjEyLjhweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48d2JyDQogICAgICAgICAgICBzdHlsZT0iZm9u
dC1zaXplOjEyLjhweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48d2JyDQogICAgICAgICAgICBzdHlsZT0i
Zm9udC1zaXplOjEyLjhweCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PHNwYW4NCiAgICAgICAgICAgIGNsYXNzPSJnbWFp
bC1pbSIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCiAgICAgICAgICAgIDUuNCBN
ZWRpYSwgTGFuZ3VhZ2UgYW5kIE1vZGFsaXR5IGluZGljYXRpb25zPC9zcGFuPg0KICAgICAg
ICAgIDxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxmb250IHNpemU9IisxIj48c3Bh
bg0KICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij48L3NwYW4+PHNw
YW4NCiAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi44cHgiPjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAg
c3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPkEgc3Bva2VuL3dyaXR0ZW4gbGFuZ3VhZ2UgdGFn
DQogICAgICAgICAgICAgICAgICBpbmNsdWRlZCBpbiBhIHRleHQgbWVkaWEgZGVzY3JpcHRp
b24gaXMgYW4gaW5kaWNhdGlvbg0KICAgICAgICAgICAgICAgICAgZm9yIHdyaXR0ZW4gbGFu
Z3VhZ2UuwqA8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNp
emU6MTIuOHB4Ij5BIHNwb2tlbi93cml0dGVuIGxhbmd1YWdlIHRhZw0KICAgICAgICAgICAg
ICAgICAgaW5jbHVkZWQgaW4gYW4gYXVkaW8gbWVkaWEgZGVzY3JpcHRpb24gaXMgYW4NCiAg
ICAgICAgICAgICAgICAgIGluZGljYXRpb24gZm9yIHNwb2tlbiBsYW5ndWFnZS4gQTwvc3Bh
bj7CoHNpZ24gbGFuZ3VhZ2UNCiAgICAgICAgICAgICAgICB0YWcgaW5jbHVkZWQgaW4gYSB2
aWRlbyBtZWRpYSBkZXNjcmlwdGlvbiBpcyBhbg0KICAgICAgICAgICAgICAgIGluZGljYXRp
b24gZm9yIHNpZ24gbGFuZ3VhZ2UgaW4gdGhlIHZpZGVvIHN0cmVhbS7CoMKgPGJyPg0KICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgPC9zcGFuPjxzcGFuIGNsYXNzPSJn
bWFpbC1pbSI+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIu
OHB4Ij5BIHNpZ24gbGFuZ3VhZ2UgY2FuIGJlDQogICAgICAgICAgICAgICAgICBpZGVudGlm
aWVkIGJ5IHRoZSBleGlzdGVuY2UgaW4gdGhlIElBTkEgcmVnaXN0cnkgb2YNCiAgICAgICAg
ICAgICAgICAgIGxhbmd1YWdlIHN1YnRhZ3MgYWNjb3JkaW5nIHRvIEJDUCA0NyBbUkZDNTY0
Nl0gb2YgdGhlDQogICAgICAgICAgICAgICAgICBsYW5ndWFnZSBzdWJ0YWcgd2l0aCB0aGUg
VHlwZSBmaWVsZCAiZXh0bGFuZyIgY29tYmluZWQNCiAgICAgICAgICAgICAgICAgIHdpdGgg
dGhlIFByZWZpeCBmaWVsZCB2YWx1ZSAic2duIi7CoDwvc3Bhbj48c3Bhbg0KICAgICAgICAg
ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPsKgPC9zcGFuPjxzcGFuDQogICAg
ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+QSBzcG9rZW4vd3JpdHRl
biBsYW5ndWFnZSB0YWcNCiAgICAgICAgICAgICAgICAgIGNhbiBiZSBpZGVudGlmaWVkIGJ5
IG5vdCBoYXZpbmcgYW55IHN1Y2ggInNnbiIgcHJlZml4Ljwvc3Bhbj48c3Bhbg0KICAgICAg
ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjwvc3Bhbj48L3NwYW4+PC9m
b250PjwvZGl2Pg0KICAgICAgICAgIDxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxm
b250IHNpemU9IisxIj48c3Bhbg0KICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6
MTIuOHB4Ij48YnI+DQogICAgICAgICAgICAgIDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQogICAg
ICAgICAgPGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PGZvbnQgc2l6ZT0iKzEiPjxz
cGFuDQogICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPlRoaXMgZG9j
dW1lbnQgZG9lcyBub3QgZGVmaW5lDQogICAgICAgICAgICAgICAgdGhlIHVzZSBvZiBzaWdu
IGxhbmd1YWdlIHRhZ3MgaW4gdGV4dCBvciBhdWRpbyBtZWRpYS48L3NwYW4+PHNwYW4NCiAg
ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+wqAgQnkgaW5jbHVkaW5n
IGEgbGFuZ3VhZ2UgdGFnDQogICAgICAgICAgICAgICAgZm9yIHNwb2tlbiBsYW5ndWFnZSBp
biBhIHZpZGVvIGRlc2NyaXB0aW9uIGFuZCB1c2luZyB0aGUNCiAgICAgICAgICAgICAgICAi
bGlwIHN5bmMiIGdyb3VwaW5nIG1lY2hhbmlzbSBkZWZpbmVkIGluIFtSRkM1ODg4XSBpdCBp
cw0KICAgICAgICAgICAgICAgIHBvc3NpYmxlIHRvIGluZGljYXRlIHN5bmNocm9uaXplZCBh
dWRpbyBhbmQgdmlkZW8gc28gYXMNCiAgICAgICAgICAgICAgICB0byBzdXBwb3J0IGxpcCBy
ZWFkaW5nLiBPdGhlciB1c2Ugb2Ygc3Bva2VuL3dyaXR0ZW4NCiAgICAgICAgICAgICAgICBs
YW5ndWFnZSB0YWdzIGluIGEgdmlkZW8gZGVzY3JpcHRpb24gKHN1Y2ggYXMgZm9yIHZpZGVv
DQogICAgICAgICAgICAgICAgZW1iZWRkZWQgdGV4dCBjYXB0aW9ucykgaXMgbm90IGRlZmlu
ZWQgaW4gdGhpcyBkb2N1bWVudC48YnI+DQogICAgICAgICAgICAgIDwvc3Bhbj48L2ZvbnQ+
PC9kaXY+DQogICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PGZvbnQg
c2l6ZT0iKzEiPjxicj4NCiAgICAgICAgICAgIDwvZm9udD48L2Rpdj4NCiAgICAgICAgICA8
ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5Vc2Ugb2YgJ2hsYW5nJyBhdHRy
aWJ1dGVzDQogICAgICAgICAgICAgIG1heSBhcHBlYXIgaW4gb3RoZXIgbWVkaWEgZGVzY3Jp
cHRpb25zLCBzdWNoIGFzICJtZXNzYWdlIg0KICAgICAgICAgICAgICBhbmQgImFwcGxpY2F0
aW9uIiBzdXBwb3J0ZWQgYnkgZnVydGhlciB3b3JrIG9yIGFwcGxpY2F0aW9uDQogICAgICAg
ICAgICAgIHNwZWNpZmljIGFncmVlbWVudHMuPC9zcGFuPiI8L2Rpdj4NCiAgICAgICAgPC9k
aXY+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+
DQogICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIE5vdiAyMSwgMjAx
NyBhdCAxMjowMCBBTSwNCiAgICAgICAgICBHdW5uYXIgSGVsbHN0csO2bSA8c3BhbiBkaXI9
Imx0ciI+Jmx0OzxhDQogICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0
cm9tQG9tbml0b3Iuc2UiIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICBtb3otZG8t
bm90LXNlbmQ9InRydWUiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT4mZ3Q7PC9z
cGFuPg0KICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICA8YmxvY2txdW90ZSBjbGFz
cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgIC44ZXg7
Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAg
ICAgICA8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPjxzcGFuIGNsYXNz
PSIiPiBEZW4NCiAgICAgICAgICAgICAgICAyMDE3LTExLTIwIGtsLiAyMzoxNiwgc2tyZXYg
QmVybmFyZCBBYm9iYTo8YnI+DQogICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQogICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj5DYW4gd2UgaW5jbHVk
ZSB0ZXh0IGZyb20gQnJpYW4ncw0KICAgICAgICAgICAgICAgICAgICBzdWdnZXN0aW9uPyBG
b3IgZXhhbXBsZTrCoA0KICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXY+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi44cHgiPiJJZiBhIHNpZ24NCiAgICAgICAgICAgICAgICAgICAg
ICAgIGxhbmd1YWdlIGlzIHNpZ25hbGVkIGluIGEgdmlkZW8gc3RyZWFtLCBpdCBpcw0KICAg
ICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0ZWQgYXMgYW4gaW5kaWNhdGlvbiB0aGF0
IHNpZ24gbGFuZ3VhZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHdpbGwgYXBwZWFyIGlu
IHRoZSB2aWRlby7CoMKgPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBz
dHlsZT0iY29sb3I6cmdiKDgwLDAsODApO2ZvbnQtc2l6ZToxMi44cHgiPkENCiAgICAgICAg
ICAgICAgICAgICAgICAgIHNpZ24gbGFuZ3VhZ2UgY2FuIGJlIGlkZW50aWZpZWQgYnkgdGhl
IGV4aXN0ZW5jZQ0KICAgICAgICAgICAgICAgICAgICAgICAgaW4gdGhlIElBTkEgcmVnaXN0
cnkgb2YgbGFuZ3VhZ2Ugc3VidGFncw0KICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3Jk
aW5nIHRvIEJDUCA0NyBbUkZDNTY0Nl0gb2YgdGhlIGxhbmd1YWdlDQogICAgICAgICAgICAg
ICAgICAgICAgICBzdWJ0YWcgd2l0aCB0aGUgVHlwZSBmaWVsZCAiZXh0bGFuZyIgY29tYmlu
ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggdGhlIFByZWZpeCBmaWVsZCB2YWx1
ZSAic2duIi7CoDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9
ImZvbnQtc2l6ZToxMi44cHgiPsKgPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICAg
ICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+QSBzcG9rZW4vd3JpdHRlbg0KICAgICAg
ICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2UgdGFnIGNhbiBiZSBpZGVudGlmaWVkIGJ5IG5v
dCBoYXZpbmcgYW55DQogICAgICAgICAgICAgICAgICAgICAgICBzdWNoICJzZ24iIHByZWZp
eC7CoDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQt
c2l6ZToxMi44cHgiPlQ8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0
eWxlPSJmb250LXNpemU6MTIuOHB4Ij5oaXMgZG9jdW1lbnQgZG9lcyBub3QNCiAgICAgICAg
ICAgICAgICAgICAgICAgIGRlZmluZSBhbnkgb3RoZXIgdXNlIGZvciBsYW5ndWFnZSB0YWdz
IGluIHZpZGVvDQogICAgICAgICAgICAgICAgICAgICAgICBtZWRpYSAoc3VjaCBhcyBob3cg
dG8gaW5kaWNhdGUgYSBkZXNpcmUgZm9yDQogICAgICAgICAgICAgICAgICAgICAgICB2aXNp
YmxlIGNhcHRpb25zKS48L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXY+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXY+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi44cHgiPlRoaXMgZG9jdW1lbnQNCiAgICAgICAgICAgICAgICAg
ICAgICAgIGRvZXMgbm90IGRlZmluZSB0aGUgdXNlIG9mIHNpZ24gbGFuZ3VhZ2UgdGFncyBp
bg0KICAgICAgICAgICAgICAgICAgICAgICAgdGV4dCBvciBhdWRpbyBtZWRpYS7CoMKgPC9z
cGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEy
LjhweCI+SWYgYSBzcG9rZW4vd3JpdHRlbg0KICAgICAgICAgICAgICAgICAgICAgICAgbGFu
Z3VhZ2UgdGFnIGlzIGluY2x1ZGVkIGluIHRleHQgbWVkaWEsIGl0DQogICAgICAgICAgICAg
ICAgICAgICAgICBpbmRpY2F0ZXMgYSBkZXNpcmUgZm9yIHdyaXR0ZW4gbGFuZ3VhZ2UuwqA8
L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6
MTIuOHB4Ij5JZiBhIHNwb2tlbi93cml0dGVuDQogICAgICAgICAgICAgICAgICAgICAgICBs
YW5ndWFnZSB0YWcgaXMgaW5jbHVkZWQgaW4gYXVkaW8gbWVkaWEsIGl0IGlzDQogICAgICAg
ICAgICAgICAgICAgICAgICBpbnRlcnByZXRlZCBhcyBhbiBpbmRpY2F0aW9uIHRoYXQgc3Bv
a2VuDQogICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSBpcyBkZXNpcmVkLsKgIFVz
aW5nIHRoZSAibGlwIHN5bmMiDQogICAgICAgICAgICAgICAgICAgICAgICBncm91cGluZyBt
ZWNoYW5pc20gZGVmaW5lZCBpbiBbUkZDNTg4OF0sIGl0IGlzDQogICAgICAgICAgICAgICAg
ICAgICAgICBwb3NzaWJsZSB0byBpbmRpY2F0ZSB0aGUgZGVzaXJlIHRvIHN5bmNocm9uaXpl
DQogICAgICAgICAgICAgICAgICAgICAgICBhdWRpbyBhbmQgdmlkZW8gc28gYXMgdG8gc3Vw
cG9ydCBsaXAgcmVhZGluZy48L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxk
aXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg
ICAgPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+VXNlIG9mIGxhbmd1YWdl
DQogICAgICAgICAgICAgICAgICAgICAgICB0YWdzIG1heSBhcHBlYXIgaW4gb3RoZXIgbWVk
aWEsIHN1Y2ggYXMNCiAgICAgICAgICAgICAgICAgICAgICAgICJtZXNzYWdlIiBhbmQgImFw
cGxpY2F0aW9uIi7CoCBTdWNoIHVzZSBtYXkgYmUNCiAgICAgICAgICAgICAgICAgICAgICAg
IHN1cHBvcnRlZCBieSBmdXJ0aGVyIHdvcmsgb3IgYXBwbGljYXRpb24NCiAgICAgICAgICAg
ICAgICAgICAgICAgIHNwZWNpZmljIGFncmVlbWVudC4iIDxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIDwvc3Bhbj4gJmx0O0dI
Jmd0O1F1aXRlIGdvb2QuIEkgc2VlIGZvdXIgc21hbGwgaXNzdWVzLiA8YnI+DQogICAgICAg
ICAgICAgIDE6ICJXSUxMIGFwcGVhciIgaXMgbm90IHJpZ2h0IGluIHRoZSBmaXJzdCBzZW50
ZW5jZS4gVGhlDQogICAgICAgICAgICAgIGluZGljYXRpb24gbWF5IGJlIGp1c3Qgb25lIG9m
IGEgc2V0IG9mIGluZGljYXRlZA0KICAgICAgICAgICAgICBsYW5ndWFnZXMuIDxicj4NCiAg
ICAgICAgICAgICAgMjogVGhlIGZpcnN0IHBhcmFncmFwaCBzYXlzIHRoYXQgd2UgZG8gbm90
IGRlZmluZSBvdGhlcg0KICAgICAgICAgICAgICB1c2Ugb2YgbGFuZ3VhZ2UgdGFncyBpbiB2
aWRlbyB0aGFuIGZvciBzaWduIGxhbmd1YWdlLCBidXQNCiAgICAgICAgICAgICAgdGhlIHNl
Y29uZCBwYXJhZ3JhcGggZGVmaW5lcyBob3cgdG8gdXNlIHRhZ3MgZm9yIHNwb2tlbg0KICAg
ICAgICAgICAgICBsYW5ndWFnZSBpbiB2aWRlby4gPGJyPg0KICAgICAgICAgICAgICAzOiBJ
IHByZWZlciB0byBzdGFydCB3aXRoIHRoZSB0aHJlZSBub3JtYWwgY2xlYXJseQ0KICAgICAg
ICAgICAgICBzdXBwb3J0ZWQgY2FzZXMuPGJyPg0KICAgICAgICAgICAgICA0OiBUaGUgaW5k
aWNhdGlvbnMgc29tZXRpbWVzIGluZGljYXRlIGRlc2lyZSwgc29tZXRpbWVzDQogICAgICAg
ICAgICAgIGNhcGFiaWxpdHkuIFRoZXJlZm9yZSB0aGUgd29yZCAiZGVzaXJlIiBpcyBub3Qg
c3VpdGFibGUgaW4NCiAgICAgICAgICAgICAgdGhlIGV4cGxhbmF0aW9ucy4gPGJyPg0KICAg
ICAgICAgICAgICA1OiBJbiB0aGUgTEMgcmV2aWV3LCB3ZSBoYWQgc29tZSByZXNpc3RhbmNl
IGFnYWluc3QgdXNpbmcNCiAgICAgICAgICAgICAgdGhlIHRlcm0gInNwb2tlbi93cml0dGVu
IGxhbmd1YWdlIHRhZyIuIEl0IGFwcGVhcnMgYWdhaW4NCiAgICAgICAgICAgICAgaW4gdGhl
IHByb3Bvc2FsLiBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSByZXNpc3RhbmNlIGFuZCBJDQog
ICAgICAgICAgICAgIGRvIG5vdCBrbm93IGhvdyBzdHJpY3QgaXQgd2FzLCBidXQgd2UgbmVl
ZCB0byBrbm93IGlmIGl0DQogICAgICAgICAgICAgIGlzIG9rIHRvIHVzZSB0aGF0IHRlcm0u
wqAgKEkgZG8gbm90IGNoYW5nZSB0aGF0IGZvciBub3cgaW4NCiAgICAgICAgICAgICAgdGhl
IHByb3Bvc2FsIGJlbG93Lik8YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICBBIHByb3Bvc2FsIHRyeWluZyB0byBhY3Qgb24gaXNz
dWVzIDEtNCBwbHVzIG90aGVyIG1pbm9yDQogICAgICAgICAgICAgIHJld29yZGluZzo8YnI+
DQogICAgICAgICAgICAgIMKgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHNwYW4NCiAgICAgICAgICAg
ICAgICBjbGFzcz0iIj48YnI+DQogICAgICAgICAgICAgICAgPHNwYW4+NS40IE1lZGlhLCBM
YW5ndWFnZSBhbmQgTW9kYWxpdHkgaW5kaWNhdGlvbnM8L3NwYW4+DQogICAgICAgICAgICAg
IDwvc3Bhbj4NCiAgICAgICAgICAgICAgPGRpdj48Zm9udCBzaXplPSIrMSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi44cHgiPjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAg
ICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAg
ICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAg
ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPkEgc3Bva2VuL3dyaXR0ZW4gbGFu
Z3VhZ2UNCiAgICAgICAgICAgICAgICAgICAgICB0YWcgaW5jbHVkZWQgaW4gYSB0ZXh0IG1l
ZGlhIGRlc2NyaXB0aW9uIGlzIGFuDQogICAgICAgICAgICAgICAgICAgICAgaW5kaWNhdGlv
biBmb3Igd3JpdHRlbiBsYW5ndWFnZS4gPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAg
ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPkEgc3Bva2VuL3dyaXR0ZW4gbGFuZ3Vh
Z2UNCiAgICAgICAgICAgICAgICAgICAgICB0YWcgaW5jbHVkZWQgaW4gYW4gYXVkaW8gbWVk
aWEgZGVzY3JpcHRpb24gaXMgYW4NCiAgICAgICAgICAgICAgICAgICAgICBpbmRpY2F0aW9u
IGZvciBzcG9rZW4gbGFuZ3VhZ2UuIEE8L3NwYW4+IHNpZ24NCiAgICAgICAgICAgICAgICAg
ICAgbGFuZ3VhZ2UgdGFnIGluY2x1ZGVkIGluIGEgdmlkZW8gbWVkaWEgZGVzY3JpcHRpb24N
CiAgICAgICAgICAgICAgICAgICAgaXMgYW4gaW5kaWNhdGlvbiBmb3Igc2lnbiBsYW5ndWFn
ZSBpbiB0aGUgdmlkZW8NCiAgICAgICAgICAgICAgICAgICAgc3RyZWFtLsKgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgPC9zcGFuPjxzcGFu
IGNsYXNzPSIiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImNvbG9yOnJn
Yig4MCwwLDgwKTtmb250LXNpemU6MTIuOHB4Ij5BIHNpZ24NCiAgICAgICAgICAgICAgICAg
ICAgICBsYW5ndWFnZSBjYW4gYmUgaWRlbnRpZmllZCBieSB0aGUgZXhpc3RlbmNlIGluIHRo
ZQ0KICAgICAgICAgICAgICAgICAgICAgIElBTkEgcmVnaXN0cnkgb2YgbGFuZ3VhZ2Ugc3Vi
dGFncyBhY2NvcmRpbmcgdG8gQkNQDQogICAgICAgICAgICAgICAgICAgICAgNDcgW1JGQzU2
NDZdIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcgd2l0aCB0aGUgVHlwZQ0KICAgICAgICAgICAg
ICAgICAgICAgIGZpZWxkICJleHRsYW5nIiBjb21iaW5lZCB3aXRoIHRoZSBQcmVmaXggZmll
bGQNCiAgICAgICAgICAgICAgICAgICAgICB2YWx1ZSAic2duIi7CoDwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjhweCI+wqA8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAg
ICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+QSBzcG9rZW4vd3JpdHRlbiBsYW5n
dWFnZQ0KICAgICAgICAgICAgICAgICAgICAgIHRhZyBjYW4gYmUgaWRlbnRpZmllZCBieSBu
b3QgaGF2aW5nIGFueSBzdWNoICJzZ24iDQogICAgICAgICAgICAgICAgICAgICAgcHJlZml4
Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+PC9zcGFuPjwvc3Bhbj48
L2ZvbnQ+PC9kaXY+DQogICAgICAgICAgICAgIDxkaXY+PGZvbnQgc2l6ZT0iKzEiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij48YnI+DQogICAgICAgICAgICAgICAgICA8L3Nw
YW4+PC9mb250PjwvZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pjxmb250IHNpemU9IisxIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+VGhpcw0KICAgICAgICAgICAgICAgICAg
ICBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgdGhlIHVzZSBvZiBzaWduIGxhbmd1YWdlDQog
ICAgICAgICAgICAgICAgICAgIHRhZ3MgaW4gdGV4dCBvciBhdWRpbyBtZWRpYS48L3NwYW4+
PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPsKg
IEJ5IGluY2x1ZGluZyBhIGxhbmd1YWdlDQogICAgICAgICAgICAgICAgICAgIHRhZyBmb3Ig
c3Bva2VuIGxhbmd1YWdlIGluIGEgdmlkZW8gZGVzY3JpcHRpb24gYW5kDQogICAgICAgICAg
ICAgICAgICAgIHVzaW5nIHRoZSAibGlwIHN5bmMiIGdyb3VwaW5nIG1lY2hhbmlzbSBkZWZp
bmVkIGluDQogICAgICAgICAgICAgICAgICAgIFtSRkM1ODg4XSBpdCBpcyBwb3NzaWJsZSB0
byBpbmRpY2F0ZSBzeW5jaHJvbml6ZWQNCiAgICAgICAgICAgICAgICAgICAgYXVkaW8gYW5k
IHZpZGVvIHNvIGFzIHRvIHN1cHBvcnQgbGlwIHJlYWRpbmcuIE90aGVyDQogICAgICAgICAg
ICAgICAgICAgIHVzZSBvZiBzcG9rZW4vd3JpdHRlbiBsYW5ndWFnZSB0YWdzIGluIGEgdmlk
ZW8NCiAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gKHN1Y2ggYXMgZm9yIHZpZGVv
IGVtYmVkZGVkIHRleHQNCiAgICAgICAgICAgICAgICAgICAgY2FwdGlvbnMpIGlzIG5vdCBk
ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuPGJyPg0KICAgICAgICAgICAgICAgICAgPC9zcGFu
PjwvZm9udD48L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj48Zm9udCBzaXplPSIrMSI+PGJy
Pg0KICAgICAgICAgICAgICAgIDwvZm9udD48L2Rpdj4NCiAgICAgICAgICAgICAgPGZvbnQg
c2l6ZT0iKzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5Vc2Ugb2YNCiAgICAg
ICAgICAgICAgICAgICdobGFuZycgYXR0cmlidXRlcyBtYXkgYXBwZWFyIGluIG90aGVyIG1l
ZGlhDQogICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbnMsIHN1Y2ggYXMgIm1lc3NhZ2Ui
IGFuZCAiYXBwbGljYXRpb24iDQogICAgICAgICAgICAgICAgICBzdXBwb3J0ZWQgYnkgZnVy
dGhlciB3b3JrIG9yIGFwcGxpY2F0aW9uIHNwZWNpZmljDQogICAgICAgICAgICAgICAgICBh
Z3JlZW1lbnRzLjwvc3Bhbj48L2ZvbnQ+PGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAg
ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0NCiAgICAgICAgICAgICAgPGRpdj4N
CiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQog
ICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAg
ICAgIDxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgIDwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8
ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICA8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij48L3NwYW4+PC9k
aXY+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDxk
aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIE5vdiAyMCwgMjAxNyBhdA0KICAgICAg
ICAgICAgICAgICAgICAgICAgMToxNCBQTSwgR3VubmFyIEhlbGxzdHLDtm0gPHNwYW4gZGly
PSJsdHIiPiZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0
bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Z3VubmFyLmhl
bGxzdHJvbUBvbW5pdG9yLnNlPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICAgICAgICAg
ICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8cD5BIG5ldyBwcm9wb3NhbCBmb3IgbmV3IHRleHQg
dGFraW5nIGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYXRlc3QgZGlzY3Vz
c2lvbiBvZiBCZXJuYXJkLCBQYXVsIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQnJpYW46PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPHA+LS0tLS1PbGQgdGV4dC0tLS08L3A+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJtXzkwNTA3Mzg5MjUx
NzY0NDU4NjBtXzQ0MzUxOTk4MzQ3NTQ5NzE5MTRtXzYzMTA0ODYyNTg1MDU1OTc5MzRuZXdw
YWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4t
Ym90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFy
aWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdl
aWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4
dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d29yZC1zcGFjaW5nOjBweDt0ZXh0
LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlh
bCI+PHNwYW4gY2xhc3M9Im1fOTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5OTgzNDc1NDk3
MTkxNG1fNjMxMDQ4NjI1ODUwNTU5NzkzNGgzIiBzdHlsZT0ibGluZS1oZWlnaHQ6MHB0O2Rp
c3BsYXk6aW5saW5lO3doaXRlLXNwYWNlOnByZS13cmFwO2ZvbnQtZmFtaWx5Om1vbm9zcGFj
ZTtmb250LXNpemU6MWVtO2ZvbnQtd2VpZ2h0OmJvbGQiPjxoMyBzdHlsZT0ibGluZS1oZWln
aHQ6MHB0O2Rpc3BsYXk6aW5saW5lO3doaXRlLXNwYWNlOnByZS13cmFwO2ZvbnQtZmFtaWx5
Om1vbm9zcGFjZTtmb250LXNpemU6MWVtO2ZvbnQtd2VpZ2h0OmJvbGQiPjUuNCBVbmRlZmlu
ZWQgQ29tYmluYXRpb25zPC9oMz48L3NwYW4+PHNwYW4+DQoNCiAgIFRoZSBiZWhhdmlvciB3
aGVuIHNwZWNpZnlpbmcgYSBub24tc2lnbmVkIGxhbmd1YWdlIHRhZyBmb3IgYSB2aWRlbw0K
ICAgbWVkaWEgc3RyZWFtLCBvciBhIHNpZ25lZCBsYW5ndWFnZSB0YWcgZm9yIGFuIGF1ZGlv
IG9yIHRleHQgbWVkaWENCiAgIHN0cmVhbSwgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1
bWVudC4NCg0KICAgVGhlIHByb2JsZW0gb2Yga25vd2luZyB3aGljaCBsYW5ndWFnZSB0YWdz
IGFyZSBzaWduZWQgYW5kIHdoaWNoIGFyZQ0KICAgbm90IGlzIG91dCBvZiBzY29wZSBvZiB0
aGlzIGRvY3VtZW50Lg0KPC9zcGFuPjwvcHJlPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLS0tLS1OZXcgdGV4dC0tLS0tLS0tLS0tLTxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDUuNCBNZWRpYSwgTGFuZ3VhZ2UgYW5kIE1vZGFsaXR5DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpbmRpY2F0aW9uczxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3Nw
YW4+IFRoZSBjb21iaW5hdGlvbiBvZiBMYW5ndWFnZSB0YWdzIGFuZA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG90aGVyIGluZm9ybWF0aW9uIGluIHRoZSBtZWRpYSBkZXNjcmlw
dGlvbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaGFsbCBiZSBjb21wb3NlZCBz
byB0aGF0IHRoZSBpbnRlbmRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGFs
aXR5IGNhbiBiZSBjb25jbHVkZWQgYnkgdGhlIG5lZ290aWF0aW5nDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcGFydGllcy4gVGhlIGZvbGxvd2luZyBjb21iaW5hdGlvbnMgb2YN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSB0YWdzIGFuZCBtZWRpYSBw
cm92aWRlIG9idmlvdXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmZvcm1hdGlv
biBhYm91dCB0aGUgbW9kYWxpdHk6IHNpZ24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBsYW5ndWFnZSB0YWdzIGluIHZpZGVvIG1lZGlhIGluZGljYXRlIHNpZ25lZA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG1vZGFsaXR5LCBsYW5ndWFnZSB0YWdzIGluIGF1ZGlv
IG1lZGlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5kaWNhdGUgc3Bva2VuIG1v
ZGFsaXR5IGFuZCBsYW5ndWFnZSB0YWdzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
aW4gdGV4dCBtZWRpYSBpbmRpY2F0ZSB3cml0dGVuIG1vZGFsaXR5LiBUaGUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBleGFtcGxlcyBpbiB0aGlzIHNwZWNpZmljYXRpb24gYXJl
IGFsbCBmcm9tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBzZXQgb2YgdGhy
ZWUgb2J2aW91cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmd1YWdlL21lZGlh
L21vZGFsaXR5IGNvbWJpbmF0aW9ucy48c3Bhbj48YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBIHNpZ24g
bGFuZ3VhZ2UgY2FuIGJlIGlkZW50aWZpZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBleGlzdGVuY2UgaW4gdGhlIElBTkEgcmVnaXN0cnkgb2YgbGFuZ3VhZ2UN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1YnRhZ3MgYWNjb3JkaW5nIHRvIEJD
UCA0NyBbUkZDNTY0Nl0gb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBs
YW5ndWFnZSBzdWJ0YWcgd2l0aCB0aGUgVHlwZSBmaWVsZA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgImV4dGxhbmciIGNvbWJpbmVkIHdpdGggdGhlIFByZWZpeCBmaWVsZA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWUgInNnbiIuIDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEEgc3BlY2lmaWMgc3Bva2VuIG9yIHdyaXR0ZW4g
bGFuZ3VhZ2UgY2FuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZSBpZGVudGlm
aWVkIGJ5IG5vdCBoYXZpbmcgYW55IHN1Y2ggInNnbiINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFByZWZpeC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPiBVc2Ugb2YgbGFuZ3Vh
Z2UgbWF5IGFwcGVhciBpbiBvdGhlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1l
ZGlhLCBzdWNoIGFzICJtZXNzYWdlIiBhbmQgImFwcGxpY2F0aW9uIi4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBWaWRlbyBtZWRpYSBtYXkgYmUgdXNlZCBmb3Igb3RoZXIgbW9k
YWxpdGllcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYW4gc2lnbmVkLCBlLmcu
IGEgdmlldyBvZiBhIHNwZWFrZXIgb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
ZXh0IGNhcHRpb25zLiBTdWNoIHVzZSBtYXkgYmUgc3VwcG9ydGVkIGJ5DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZnVydGhlciB3b3JrIG9yIGFwcGxpY2F0aW9uIHNwZWNpZmlj
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYWdyZWVtZW50cyBmb3IgZXZhbHVhdGlv
biBvZiB0aGUgaW50ZW5kZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RhbGl0
eS4gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1FbmQgb2YgbmV3
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4dC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tPHdicj4tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9Im1fOTA1
MDczODkyNTE3NjQ0NTg2MGg1Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PHA+IDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY2xhc3M9Im1fOTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5OTgzNDc1
NDk3MTkxNG1vei1jaXRlLXByZWZpeCI+RGVuDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMjAxNy0xMS0yMCBrbC4gMjE6NDQsIHNrcmV2IEd1bm5hcg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEhlbGxzdHLDtm06PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdiBjbGFzcz0ibV85MDUwNzM4OTI1MTc2NDQ1ODYwaDUiPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlbiAyMDE3LTExLTIwIGtsLiAxOTo0MSwg
c2tyZXYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXJuYXJkIEFib2Jh
Ojxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYg
ZGlyPSJsdHIiPkd1bm5hciBzYWlkOsKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
dj4iPHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0
eWxlPSJmb250LXNpemU6MTIuOHB4Ij41LjQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIE1lZGlhLCBMYW5ndWFnZSBhbmQgTW9kYWxpdHkNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZGljYXRpb25zPC9zcGFuPjwv
ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnIgc3R5bGU9
ImZvbnQtc2l6ZToxMi44cHgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+VGhlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tYmluYXRpb24gb2YgTGFuZ3VhZ2UgdGFn
cyBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdGhlciBp
bmZvcm1hdGlvbiBpbiB0aGUgbWVkaWENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBkZXNjcmlwdGlvbnMgc2hvdWxkIGJlIGNvbXBvc2VkDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc28gdGhhdCB0aGUgaW50ZW5kZWQgbW9k
YWxpdHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYW4gYmUg
Y29uY2x1ZGVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG5lZ290aWF0aW5nIHBhcnRpZXMuICI8L3NwYW4+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij48YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PjxzcGFuDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEy
LjhweCI+W0JBXQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
SXMgdGhlICJzaG91bGQiIGludGVuZGVkIHRvIGJlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBub3JtYXRpdmU/IDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmx0O0dIJmd0O1lvdSBhcmUgcmlnaHQgdGhhdCBTSE9VTEQNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzaG91bGQgYmUgYXZvaWRlZCBhbmQgaXQgd291bGQgYmUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZXR0ZXIgdG8gc2F5IE1VU1Qg
aWYgd2UgY2FuLiBCdXQgSQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNh
biBpbWFnaW5lIGxpbWl0ZWQgYXJlYSBhcHBsaWNhdGlvbnMNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBoYXZpbmcgYXBwbGljYXRpb24gYWdyZWVtZW50cyBlLmcuDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2F5aW5nIHRoYXQgYSBub24tc2ln
bmVkIGxhbmd1YWdlIHRhZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu
IHZpZGVvIG1lZGlhIG1lYW5zIGEgdmlldyBvZiBhDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGFsa2luZyBwZXJzb24uIMKgIFRoZSBuZWdvdGlhdGluZw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9ucyBrbm93IGFib3V0IHRo
aXMgYWdyZWVtZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc28gdGhl
eSBjYW4gbWFrZSB0aGUgY29uY2x1c2lvbi4gU28sDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgaWYgc3VjaCBzaXR1YXRpb25zIGNhbiBiZSBpbmNsdWRlZCBpbg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhvdyB0aGUgcGFydGllcyBtYWtlIHRo
ZWlyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uY2x1c2lvbnMsIHdl
IGNhbiBjaGFuZ2UgdG8gTVVTVC7CoCA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PHNwYW4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIu
OHB4Ij5UaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv
bGxvd2luZyBjb21iaW5hdGlvbnMgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGxhbmd1YWdlIHRhZ3MgYW5kIG1lZGlhDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlIG9idmlvdXMgaW5mb3JtYXRpb24N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFib3V0IHRoZSBt
b2RhbGl0eTogc2lnbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbGFuZ3VhZ2UgdGFncyBpbiB2aWRlbyBtZWRpYQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaW5kaWNhdGUgc2lnbmVkIG1vZGFsaXR5Li4uwqA8L3Nw
YW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0
eWxlPSJmb250LXNpemU6MTIuOHB4Ij5BDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBzaWduIGxhbmd1YWdlIGNhbiBiZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaWRlbnRpZmllZCBieSB0aGUgZXhpc3RlbmNlIGlu
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgSUFOQSBy
ZWdpc3RyeSBvZiBsYW5ndWFnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgc3VidGFncyBhY2NvcmRpbmcgdG8gQkNQIDQ3DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBbUkZDNTY0Nl0gb2YgdGhlIGxhbmd1YWdlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdWJ0YWcgd2l0aCB0
aGUgVHlwZSBmaWVsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgImV4dGxhbmciIGNvbWJpbmVkIHdpdGggdGhlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBQcmVmaXggZmllbGQgdmFsdWUgInNnbiIuwqDCoDwvc3Bh
bj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5
bGU9ImZvbnQtc2l6ZToxMi44cHgiPkENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHNwZWNpZmljIHNwb2tlbiBvciB3cml0dGVuDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSBjYW4gYmUgaWRlbnRpZmll
ZCBieQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IGhh
dmluZyBhbnkgc3VjaCAic2duIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgUHJlZml4Ljwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PHNwYW4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuOHB4
Ij5Vc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mIGxh
bmd1YWdlIG1heSBhcHBlYXIgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG90aGVyIG1lZGlhLCBzdWNoIGFzICJtZXNzYWdlIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kICJhcHBsaWNhdGlvbiIuIFZpZGVv
IG1lZGlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXkg
YmUgdXNlZCBmb3Igb3RoZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG1vZGFsaXRpZXMgdGhhbiBzaWduZWQuIFN1Y2gNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVzZSBtYXkgYmUgc3VwcG9ydGVkIGJ5DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmdXJ0aGVyIHdvcmsgb3Ig
YXBwbGljYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHNwZWNpZmljIGFncmVlbWVudHMgb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGluZGljYXRpb25zIGZvciBldmFsdWF0aW9uIG9mDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgaW50ZW5kZWQgbW9kYWxpdHku
PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+wqA8L3NwYW4+IjxzcGFuDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhw
eCI+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bh
bj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48
c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9
ImZvbnQtc2l6ZToxMi44cHgiPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5bQkFdDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBc3N1bWUgd2UgY2FuIGNvbmZpcm0gdGhl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5pc20g
Zm9yIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzaWduZWQvbm9uLXNpZ25lZCBsYW5ndWFnZXMsDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzIHBhcnQgc2VlbXMgcmVsYXRpdmVseQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29saWQuwqA8L3Nw
YW4+PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl
PSJmb250LXNpemU6MTIuOHB4Ij48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2PjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+c3Bva2VuDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSB0YWdzIGZvciBhdWRp
byBtZWRpYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5k
aWNhdGUgc3Bva2VuIG1vZGFsaXR5IGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgd3JpdHRlbiBsYW5ndWFnZSB0YWdzIGZvciB0ZXh0DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWRpYSBpbmRpY2F0ZSB3cml0
dGVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RhbGl0
eS4gVGhlIGV4YW1wbGVzIGluIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHNwZWNpZmljYXRpb24gYXJlIGFsbCBmcm9tDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzIHNldCBvZiB0aHJlZSBvYnZpb3Vz
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZS9t
ZWRpYS9tb2RhbGl0eQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgY29tYmluYXRpb25zLjwvc3Bhbj48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2PltCQV3CoCBUaGlzIGlzIHdoZXJlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGdyb3VuZCBnZXRzIGxlc3Mgc29saWQgLSB3ZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbid0IHJlYWxseSBoYXZlIGEg
Z2VuZXJhbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lY2hh
bmlzbSBmb3IgZGlzdGluZ3Vpc2hpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBzcG9rZW4gYW5kIHdyaXR0ZW4gbW9kYWxpdHkNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBhbW9uZyBub24tc2lnbmVkIGxhbmd1YWdlcy4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQZXJoYXBzIHdlIHNo
b3VsZCBqdXN0IHNheQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICJsYW5ndWFnZSB0YWdzIGluIGF1ZGlvIG1lZGlhDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaW5kaWNhdGUgc3Bva2VuIG1vZGFsaXR5IGFuZA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmd1YWdlIHRhZ3MgaW4gdGV4
dCBtZWRpYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZGlj
YXRlIHdyaXR0ZW4gbW9kYWxpdHkiLiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1
b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFllcywgcmlnaHQsIHRo
YXQgaXMgYmV0dGVyIHdvcmRpbmcuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHdW5uYXI8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGRp
cj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48
YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxiciBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyIHN0eWxlPSJmb250LXNpemU6
MTIuOHB4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2
Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1
b3RlIj5PbiBNb24sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Tm92IDIwLCAyMDE3IGF0IDk6MjUgQU0sIEd1bm5hcg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEhlbGxzdHLDtm0gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YQ0K
aHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIgdGFyZ2V0PSJfYmxh
bmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSI+Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlPC9hPiZndDs8
L3NwYW4+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1
b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2MNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNvbGlkO3BhZGRpbmctbGVm
dDoxZXgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
diB0ZXh0PSIjMDAwMDAwIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPHA+SXQgaXMgbm90IHRoZSBzaWduZWQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZXMgdGhhdCBhcmUg
Y2F1c2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRoZSBwcm9ibGVtLiBJdCBpcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzcG9rZW4gYW5kIHdyaXR0ZW4sIHdoZW4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2VkIGluIG90aGVyIG1lZGlh
IHRoYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
aGUgb2J2aW91cyBhdWRpbyBhbmQgdGV4dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIG1lZGlhLiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPHA+QW5kIHdlIHNob3VsZCBzcGVjaWZ5DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hhdCBpcyBvYnZpb3VzIGFu
ZCB3ZWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZGVmaW5lZCBhbmQgbm90LCBzbyBoZXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaXMgYSBuZXcgc2hvcnRlciBwcm9wb3NhbA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciBzZWN0aW9uIDUuNC48
L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwPi0t
LS0tT2xkIHRleHQtLS0tPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8cHJlIGNsYXNzPSJtXzkwNTA3Mzg5MjUxNzY0NDU4NjBtXzQ0MzUxOTk4
MzQ3NTQ5NzE5MTRtXzYzMTA0ODYyNTg1MDU1OTc5MzRuZXdwYWdlIiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpy
Z2IoMCwwLDApO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9y
bWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVy
LXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQt
dHJhbnNmb3JtOm5vbmU7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6
aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbCI+PHNwYW4gY2xhc3M9Im1f
OTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5OTgzNDc1NDk3MTkxNG1fNjMxMDQ4NjI1ODUw
NTU5NzkzNGgzIiBzdHlsZT0ibGluZS1oZWlnaHQ6MHB0O2Rpc3BsYXk6aW5saW5lO3doaXRl
LXNwYWNlOnByZS13cmFwO2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtmb250LXNpemU6MWVtO2Zv
bnQtd2VpZ2h0OmJvbGQiPjxoMyBzdHlsZT0ibGluZS1oZWlnaHQ6MHB0O2Rpc3BsYXk6aW5s
aW5lO3doaXRlLXNwYWNlOnByZS13cmFwO2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtmb250LXNp
emU6MWVtO2ZvbnQtd2VpZ2h0OmJvbGQiPjUuNCBVbmRlZmluZWQgQ29tYmluYXRpb25zPC9o
Mz48L3NwYW4+PHNwYW4+DQoNCiAgIFRoZSBiZWhhdmlvciB3aGVuIHNwZWNpZnlpbmcgYSBu
b24tc2lnbmVkIGxhbmd1YWdlIHRhZyBmb3IgYSB2aWRlbw0KICAgbWVkaWEgc3RyZWFtLCBv
ciBhIHNpZ25lZCBsYW5ndWFnZSB0YWcgZm9yIGFuIGF1ZGlvIG9yIHRleHQgbWVkaWENCiAg
IHN0cmVhbSwgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIHBy
b2JsZW0gb2Yga25vd2luZyB3aGljaCBsYW5ndWFnZSB0YWdzIGFyZSBzaWduZWQgYW5kIHdo
aWNoIGFyZQ0KICAgbm90IGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPC9z
cGFuPjwvcHJlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAtLS0tLU5ldyB0ZXh0LS0tLS0tLS0tLS0tPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA1LjQgTWVkaWEsIExhbmd1YWdlIGFuZA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb2RhbGl0eSBpbmRpY2F0
aW9uczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUg
Y29tYmluYXRpb24gb2YgTGFuZ3VhZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGFncyBhbmQgb3RoZXIgaW5mb3JtYXRpb24NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gdGhlIG1lZGlhIGRlc2NyaXB0
aW9ucw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaG91
bGQgYmUgY29tcG9zZWQgc28gdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0aGUgaW50ZW5kZWQgbW9kYWxpdHkgY2FuIGJlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbmNsdWRlZCBieSB0aGUgbmVn
b3RpYXRpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
cGFydGllcy4gVGhlIGZvbGxvd2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjb21iaW5hdGlvbnMgb2YgbGFuZ3VhZ2UNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFncyBhbmQgbWVkaWEgcHJvdmlkZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvYnZpb3VzIGlu
Zm9ybWF0aW9uIGFib3V0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHRoZSBtb2RhbGl0eTogc2lnbiBsYW5ndWFnZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0YWdzIGluIHZpZGVvIG1lZGlhIGluZGljYXRl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBt
b2RhbGl0eSwgc3Bva2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGxhbmd1YWdlIHRhZ3MgZm9yIGF1ZGlvDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG1lZGlhIGluZGljYXRlIHNwb2tlbg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RhbGl0eSBhbmQgd3JpdHRl
bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFn
ZSB0YWdzIGZvciB0ZXh0IG1lZGlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGluZGljYXRlIHdyaXR0ZW4gbW9kYWxpdHkuDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBleGFtcGxlcyBpbiB0aGlzDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljYXRp
b24gYXJlIGFsbCBmcm9tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHRoaXMgc2V0IG9mIHRocmVlIG9idmlvdXMNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2UvbWVkaWEvbW9kYWxpdHkNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tYmluYXRpb25zLjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBIHNpZ24gbGFu
Z3VhZ2UgY2FuIGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGlkZW50aWZpZWQgYnkgdGhlIGV4aXN0ZW5jZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpbiB0aGUgSUFOQSByZWdpc3RyeSBvZg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSBzdWJ0YWdz
IGFjY29yZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0byBCQ1AgNDcgW1JGQzU2NDZdIG9mIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSBzdWJ0YWcgd2l0aCB0aGUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHlwZSBmaWVsZCAiZXh0bGFu
ZyINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tYmlu
ZWQgd2l0aCB0aGUgUHJlZml4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGZpZWxkIHZhbHVlICJzZ24iLiA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEEgc3BlY2lmaWMgc3Bva2VuIG9yIHdyaXR0ZW4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGFuZ3VhZ2Ug
Y2FuIGJlIGlkZW50aWZpZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgYnkgbm90IGhhdmluZyBhbnkgc3VjaCAic2duIg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQcmVmaXguPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVzZSBvZiBsYW5ndWFnZSBtYXkgYXBwZWFy
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIG90aGVy
IG1lZGlhLCBzdWNoIGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICJtZXNzYWdlIiBhbmQgImFwcGxpY2F0aW9uIi4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgVmlkZW8gbWVkaWEgbWF5IGJlIHVzZWQgZm9y
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyIG1v
ZGFsaXRpZXMgdGhhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBzaWduZWQuIFN1Y2ggdXNlIG1heSBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzdXBwb3J0ZWQgYnkgZnVydGhlciB3b3JrIG9yDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9uIHNw
ZWNpZmljDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFn
cmVlbWVudHMgb3IgaW5kaWNhdGlvbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZm9yIGV2YWx1YXRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVuZGVkIG1vZGFsaXR5LiA8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tPHdicj4tLS0tLS0tRW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG9mIG5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0ZXh0LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0t
LS0tLS0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGFz
cz0ibV85MDUwNzM4OTI1MTc2NDQ1ODYwbV80NDM1MTk5ODM0NzU0OTcxOTE0aDUiPjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYN
CmNsYXNzPSJtXzkwNTA3Mzg5MjUxNzY0NDU4NjBtXzQ0MzUxOTk4MzQ3NTQ5NzE5MTRtXzYz
MTA0ODYyNTg1MDU1OTc5MzRtb3otY2l0ZS1wcmVmaXgiPkRlbg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDE3LTExLTIwIGtsLiAxNTo1
NSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
c2tyZXYgUmFuZGFsbCBHZWxsZW5zOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+QXQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNzo0NyBQ
TSAtMDgwMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAxMS8xOS8xNywgQmVybmFyZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBBYm9iYSB3cm90ZTogPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0i
Y2l0ZSI+wqAiU28NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBsZXQncyBkZWxldGUgU2VjdGlvbg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDUuNCBhbmQgYmUgZG9uZSB3aXRoDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXQu
wqAgTmVpdGhlciBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzdGF0ZW1lbnRzIGlzDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmVjZXNzYXJ5LiIgPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoFtC
QV3CoCBJIGFncmVlIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBTZWN0aW9uIDUuNCBkb2VzIG5vdA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFkZCBtdWNoIHZhbHVlIGFz
IGl0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3RhbmRzLiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgIk5vbi1zaWduZWQiIGlzIG5vdA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzZWQgb3V0c2lkZSBv
Zg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFNlY3Rpb24gNS40LCBzbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZXJlIHdvdWxkIG5vdA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFwcGVhciB0byBiZSBhIG5lZWQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBk
ZWZpbmUgaXQgaWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBTZWN0aW9uIDUuNCB3ZXJlIHRvDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmUgZGVsZXRlZC4gPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoEhv
d2V2ZXIsIHRoZSB0ZXJtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgInNpZ25lZCIgaXMgdXNlZCBpbg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDcgb3RoZXIgcGxhY2VzIGluDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhl
IGRvY3VtZW50IG90aGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGhhbiBpbiBTZWN0aW9uIDUuNC4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCdXQg
bm9uZSBvZiB0aG9zZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBpbnN0YW5jZXMgYXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG5vcm1hdGl2ZS4gPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0i
Y2l0ZSI+wqBTbyB3ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG1heSBuZWVkIHRvIGZpbmQgYQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZmVyZW5jZSB0byBkZWZpbmUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0
IHRlcm0uIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIEJlY2F1c2UgdGhlIHVzZXMgb2YNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHRlcm0gYXJlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlc2Ny
aXB0aXZlIGFuZCBtb3N0bHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYmFja2dyb3VuZCwgSSBkbyBub3QNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpbmsgd2UgbmVlZCB0byBhZGQg
YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk
ZWZpbml0aW9uIG9yIGV2ZW4gYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICByZWZlcmVuY2UgdG8gYQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbml0aW9uIG9mIHRoZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0ZXJtLiA8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LS1SYW5kYWxsIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA8YmxvY2txdW90ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9ImNpdGUiPiA8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBJZiBHdW5uYXIn
cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHN1Z2dlc3RlZCBkZWZpbml0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY2FuIGJlIGNvbmZpcm1lZCzCoA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgbWlnaHQgYmUg
YXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzaW1wbGUgYXMgYWRkaW5nIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICByZWZlcmVuY2UgdG8gdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSUFOQSBsYW5ndWFnZSB0YWcN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy
ZXBvc2l0b3J5LiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgT24gU3VuLCBOb3YgMTksDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAxNyBhdCAzOjUyIFBNLA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJh
bmRhbGwgR2VsbGVucyAmbHQ7PGENCmNsYXNzPSJtXzkwNTA3Mzg5MjUxNzY0NDU4NjBtXzQ0
MzUxOTk4MzQ3NTQ5NzE5MTRtXzYzMTA0ODYyNTg1MDU1OTc5MzRtb3otdHh0LWxpbmstcmZj
MjM5NkUiDQpocmVmPSJtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPiZsdDttYWlsdG86cmcraWV0ZkBy
YW5keS5wZW5zaXZlPHdicj4ub3JnJmd0OzwvYT48YQ0KY2xhc3M9Im1fOTA1MDczODkyNTE3
NjQ0NTg2MG1fNDQzNTE5OTgzNDc1NDk3MTkxNG1fNjMxMDQ4NjI1ODUwNTU5NzkzNG1vei10
eHQtbGluay1hYmJyZXZpYXRlZCINCmhyZWY9Im1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNp
dmUub3JnIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cmcraWV0
ZkByYW5keS5wZW5zaXZlLm9yZzwvYT48d2JyPiZndDsNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTogPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoE15IHZp
ZXcgb2YgaXNzdWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAjNDMgcmVtYWlucyB0aGF0IHdlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG8gbm90IG5lZWQgdG8NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZ5IGEg
bWVjaGFuaXNtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZm9yIGRldGVybWluaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggdGFncyBhcmUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWduZWQuwqAgSW4gdGhl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZW1haWwgZGlzY3Vzc2lvbiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHRoZSBwYXN0IG1vbnRoIG9yDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc28sIEkgZmVhciB3ZSBhcmUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk
cmlmdGluZyBpbnRvIGFkZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbXBsZXhpdHkgcmF0aGVyDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhbiByZW1vdmluZyBpdC7C
oCBJDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgdGhpbmsgdGhlIHdheQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZvcndhcmQgaXMgdG8ga2VlcA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgZG9jdW1lbnQgYXMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaW1w
bGUgYXMgcG9zc2libGUuwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBBcyBCZXJuYXJkIG5vdGVzIGluDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGlzIGVtYWlsIG9mIDEwLzIz
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRoZXJlIGlzIG5vIGJlbmVmaXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBpbiB0aGlzIGNhc2Ugb2YNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHBsaWNpdGx5IHNheWluZw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo
YXQgY2VydGFpbiB0aGluZ3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBhcmUgbm90IGRlZmluZWQuwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaW5jZSB0aGUgZG9jdW1lbnQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk
b2VzIG5vdCBkZWZpbmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0aGVtLCB0aGV5IGFyZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuZGVmaW5lZCBpbiB0aGUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2N1bWVudC4g
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICDCoEF0IDY6NTEgUE0gLTA3MDANCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAxMC8yMy8xNywgQmVybmFyZA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFib2JhIHdyb3Rl
OiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgIEluIG90aGVyIHdvcmRzLGl0DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgbm90IGNsZWFyIHRvIG1lDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaG93IFNl
Y3Rpb24gNS40J3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBkaXNjdXNzaW9uIG9mIHNjb3BlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW1wcm92ZXMgb3INCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGFyaWZpZXMgdGhl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
c2l0dWF0aW9uIGluIGFueSB3YXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAtIGFuZCB0aGVyZSBpcyBzb21lDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9zc2liaWxpdHkgdGhh
dCBpdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNvdWxkIGNhdXNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcHJvYmxlbXMuIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoEkgYmVsaWV2ZSBj
b21tZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIzQzIHNob3VsZCBiZSBjbG9zZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBhcyBubyBsb25nZXINCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcHBsaWNhYmxlLCBzaW5j
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRoZSB0ZXh0IGFnYWluc3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB3aGljaCBpdCB3YXMNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnZW5lcmF0ZWQgaGFzIGJlZW4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWxldGVk
LiAoSSd2ZSBzYWlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGhpcyBiZWZvcmUsIGFuZCBJDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmVsaWV2ZSBpdCByZW1haW5zDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNh
c2UuKSA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgVGhlIGNvbW1lbnQgZnJvbQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoICM0MyBkZXJpdmVzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2FzIG1h
ZGUgYWdhaW5zdCBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdmVyc2lvbiBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkb2N1bWVudCB0aGF0IGhhZA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQgZXhwbGlj
aXRseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGRpc2N1c3Npbmcgc2lnbmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdmVyc3VzIHVuc2lnbmVkDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFncy7CoCBUaGF0IHRleHQg
d2FzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3Vic2VxdWVudGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZGVsZXRlZC4gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoEhlcmUgaXMgdGhlIGNvbW1lbnQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm
cm9tIHdoaWNoICM0Mw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRlcml2ZWQ6IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgNS4yLsKgIE5ldw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdodW1p
bnRsYW5nLXNlbmQnDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJ2h1bWludGxhbmctcmVjdicNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdHRyaWJ1dGVzIDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDC
oMKgwqAgTm90ZSB0aGF0IHdoaWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgc2lnbmVkIGxhbmd1YWdlIHRhZ3MNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcmUgdXNlZCB3aXRo
IGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB2aWRlbyBzdHJlYW0gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgIHRvIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCBpbmRpY2F0ZSBzaWduDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGFu
Z3VhZ2UsIGEgc3Bva2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbGFuZ3VhZ2UgdGFnIGZvciBhDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmlkZW8gc3RyZWFtIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCBp
biA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgwqDCoMKgwqAgcGFyYWxsZWwgd2l0aA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuIGF1ZGlvIHN0cmVhbSB3aXRoDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHNh
bWUgc3Bva2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbGFuZ3VhZ2UgdGFnIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCBpbmRpY2F0ZXMgYQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcXVlc3Qg
Zm9yIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBzdXBwbGVtZW50YWwgdmlkZW8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBzdHJlYW0gdG8gc2VlIHRoZSA8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAg
c3BlYWtlci4gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoCBBbmQgdGhlcmUncyBhDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ltaWxhciBwYXJhZ3JhcGggaW4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA1
LjQ6IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqDCoMKgwqAgQSBzcG9rZW4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsYW5ndWFnZSB0YWcgZm9yIGENCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2aWRlbyBz
dHJlYW0gaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjb25qdW5jdGlvbiB3aXRoIGFuDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCBhdWRpbyA8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKg
wqDCoMKgIHN0cmVhbSB3aXRoIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHNhbWUgbGFuZ3VhZ2UgbWlnaHQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmRpY2F0ZSBhIHJl
cXVlc3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBmb3IgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgwqDCoMKgIHN1cHBsZW1lbnRhbA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpZGVvIHRvIHNlZSB0aGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVh
a2VyLiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoCBJIHRoaW5rIHRoaXMNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZWNoYW5pc20gbmVlZHMgdG8NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZSBk
ZXNjcmliZWQgbW9yZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGV4YWN0bHksIGFuZCBpbiA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgcGFydGljdWxhciwgaXQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaG91
bGQgbm90IGRlcGVuZCBvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZSBVQSB1bmRlcnN0YW5kaW5nDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIGxhbmd1
YWdlIHRhZ3MgYXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3Bva2VuIGxhbmd1YWdlDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFncy7CoCBJdCBzZWVtcyB0bw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lIHRoYXQg
YSA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgwqAgd29ya2FibGUgcnVsZSBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgdGhlcmUgaXMgYW4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdWRpbyBzdHJlYW0g
YW5kIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB2aWRlbyBzdHJlYW0gYW5kIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICDCoCB0aGV5IHNwZWNpZnkNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleGFjdGx5IHRoZSBz
YW1lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbGFuZ3VhZ2UgdGFnIGluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgdGhlaXIgcmVzcGVjdGl2ZSA8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgaHVtaW50bGFuZw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF0
dHJpYnV0ZXMuwqAgSW4gdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNhc2UsIGl0IGlzIGENCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1ZXN0IGZvciBhIHNwb2tlbg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICDCoCBsYW5ndWFnZSB3aXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc2ltdWx0YW5lb3VzIHZpZGVvDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIHNwZWFrZXIsIGFu
ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRob3NlIHJlcXVlc3RzIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICDCoCBzaG91bGQgYmUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zaWRlcmVkIHNhdGlzZmllZA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9u
bHkgaWYgYm90aCBzdHJlYW1zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY2FuIGJlIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCBlc3RhYmxpc2hlZC4gPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqBUaGUgb2ZmZW5kaW5nIHRleHQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHdhcyBpbiA1LjIgYW5kDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNS40IHdhcyBkZWxl
dGVkLiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgVGhlIG9ubHkgcmVtYWluaW5nDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4dCB0aGF0IGV2ZW4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZW50aW9u
cyB0aGUgaXNzdWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBpcyBTZWN0aW9uIDUuNDogPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqAgVGhlIGJlaGF2aW9y
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
d2hlbiBzcGVjaWZ5aW5nIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBub24tc2lnbmVkIGxhbmd1YWdlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFnIGZvciBhIHZpZGVvIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICDCoMKgwqAgbWVkaWEgc3RyZWFtLCBvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGEgc2lnbmVkIGxhbmd1YWdlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFnIGZvciBhbiBh
dWRpbyBvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHRleHQgbWVkaWEgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCBzdHJlYW0sIGlzIG5vdA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmluZWQgaW4g
dGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGRvY3VtZW50LiA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCBUaGUgcHJvYmxlbSBvZg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtub3dpbmcgd2hp
Y2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBsYW5ndWFnZSB0YWdzIGFyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHNpZ25lZCBhbmQgd2hpY2ggYXJlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCBub3Qg
aXMgb3V0IG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgc2NvcGUgb2YgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGRvY3VtZW50LiA8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgU28sIGxldCdzIGRl
bGV0ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFNlY3Rpb24gNS40IGFuZCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGRvbmUgd2l0aCBpdC7CoA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5laXRoZXIgb2YgdGhlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Rh
dGVtZW50cyBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG5lY2Vzc2FyeS4gPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoC0tIDxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoFJhbmRhbGwgR2VsbGVu
cyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgwqBPcGluaW9ucyBhcmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBwZXJzb25hbDvCoMKgwqAgZmFjdHMNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcmUgc3VzcGVjdDvC
oMKgwqAgSQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHNwZWFrIGZvciBteXNlbGYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBvbmx5IDxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoC0tLS0tLS0tLS0tLS0tDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmFuZG9t
bHkgc2VsZWN0ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0YWc6IC0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoE1ha2UgaXQgcmlnaHQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWZv
cmUgeW91IG1ha2UgaXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBmYXN0ZXIuIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwcmUgY2xhc3M9Im1f
OTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5OTgzNDc1NDk3MTkxNG1fNjMxMDQ4NjI1ODUw
NTU5NzkzNG1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj48c3BhbiBjbGFzcz0ibV85MDUwNzM4
OTI1MTc2NDQ1ODYwbV80NDM1MTk5ODM0NzU0OTcxOTE0SE9FblpiIj48Zm9udCBjb2xvcj0i
Izg4ODg4OCI+LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0t
LS0tLS0tDQpHdW5uYXIgSGVsbHN0csO2bQ0KT21uaXRvcg0KPC9mb250Pjwvc3Bhbj48c3Bh
bj48YSBjbGFzcz0ibV85MDUwNzM4OTI1MTc2NDQ1ODYwbV80NDM1MTk5ODM0NzU0OTcxOTE0
bV82MzEwNDg2MjU4NTA1NTk3OTM0bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt
YWlsdG86Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNlIiB0YXJnZXQ9Il9ibGFuayIgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+DQor
NDYgNzA4IDIwNCAyODg8L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxwcmUgY2xhc3M9Im1fOTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5
OTgzNDc1NDk3MTkxNG1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSANCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0NCkd1bm5hciBIZWxsc3Ryw7Zt
DQpPbW5pdG9yDQo8YSBjbGFzcz0ibV85MDUwNzM4OTI1MTc2NDQ1ODYwbV80NDM1MTk5ODM0
NzU0OTcxOTE0bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Z3VubmFy
LmhlbGxzdHJvbUBvbW5pdG9yLnNlIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIj5ndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2U8L2E+DQorNDYgNzA4IDIwNCAy
ODg8L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGZpZWxkc2V0DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBjbGFzcz0ibV85MDUwNzM4OTI1MTc2NDQ1ODYwbV80
NDM1MTk5ODM0NzU0OTcxOTE0bWltZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPHdicj5fX19fX19fX19fX19fX19fXw0KU0xJTSBtYWlsaW5nIGxpc3QNCjxhIGNs
YXNzPSJtXzkwNTA3Mzg5MjUxNzY0NDU4NjBtXzQ0MzUxOTk4MzQ3NTQ5NzE5MTRtb3otdHh0
LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpTTElNQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5TTElNQGlldGYub3JnPC9hPg0KPGEg
Y2xhc3M9Im1fOTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5OTgzNDc1NDk3MTkxNG1vei10
eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9zbGltIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2w8d2JyPmlzdGluZm8vc2xpbTwvYT4NCjwv
cHJlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvYmxvY2txdW90
ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPHNwYW4+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cHJl
IGNsYXNzPSJtXzkwNTA3Mzg5MjUxNzY0NDU4NjBtXzQ0MzUxOTk4MzQ3NTQ5NzE5MTRtb3ot
c2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS08d2JyPi0tLS0tLS0tLS0tDQpHdW5uYXIgSGVsbHN0csO2bQ0KT21uaXRvcg0KPGEgY2xh
c3M9Im1fOTA1MDczODkyNTE3NjQ0NTg2MG1fNDQzNTE5OTgzNDc1NDk3MTkxNG1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRv
ci5zZSIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Z3VubmFyLmhl
bGxzdHJvbUBvbW5pdG9yLnNlPC9hPg0KKzQ2IDcwOCAyMDQgMjg4PC9wcmU+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICA8YnI+
DQogICAgICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJtXzkwNTA3Mzg5MjUxNzY0NDU4NjBt
b3otc2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS08d2JyPi0tLS0tLS0tLS0tDQpHdW5uYXIgSGVsbHN0csO2bQ0KT21uaXRvcg0KPGEg
Y2xhc3M9Im1fOTA1MDczODkyNTE3NjQ0NTg2MG1vei10eHQtbGluay1hYmJyZXZpYXRlZCIg
aHJlZj0ibWFpbHRvOmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZSIgdGFyZ2V0PSJfYmxh
bmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Z3VubmFyLmhlbGxzdHJvbUBvbW5pdG9yLnNl
PC9hPg0KKzQ2IDcwOCAyMDQgMjg4PC9wcmU+DQogICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPC9i
bG9ja3F1b3RlPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGJyPg0KICAgICAgPC9kaXY+
DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8cHJlIGNsYXNzPSJtb3otc2ln
bmF0dXJlIiBjb2xzPSI3MiI+LS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KR3VubmFyIEhlbGxzdHLDtm0NCk9tbml0b3INCjxhIGNsYXNzPSJtb3ot
dHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9t
bml0b3Iuc2UiPmd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZTwvYT4NCis0NiA3MDggMjA0
IDI4ODwvcHJlPg0KICA8L2JvZHk+DQo8L2h0bWw+DQo=
--------------65B0D4D6C0C82606FC8C0720--


From nobody Tue Nov 21 13:54: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 83B3B1275AB for ; Tue, 21 Nov 2017 13:54:21 -0800 (PST)
X-Quarantine-ID: <61nDRlj5-63u>
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] 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 61nDRlj5-63u for ; Tue, 21 Nov 2017 13:54:20 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93A371270AB for ; Tue, 21 Nov 2017 13:54:20 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 21 Nov 2017 13:54:25 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <4efeeff4-bcd7-661e-93c9-23e6fec3704b@alum.mit.edu>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>   <4efeeff4-bcd7-661e-93c9-23e6fec3704b@alum.mit.edu>
X-Mailer: Eudora for Mac OS X
Date: Tue, 21 Nov 2017 13:54:16 -0800
To: Paul Kyzivat , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 21:54:21 -0000

At 3:53 PM -0500 11/21/17, Paul Kyzivat wrote:

>  I wonder if they do it even when it isn't true.
>
>  For instance, consider a movie that was created in English. So the 
> actors are speaking English, the audio is labeled as English, and 
> there is lip sync.
>
>  Now take the same movie and dub it in Spanish. Now the audio ought 
> to be labeled as Spanish. But lip sync should no longer be 
> indicated. Is that what happens in practice?
>
>  Of course, a totally deaf English speaking lip reader will 
> understand both equally well. But there may not be anything in the 
> signaling to indicate that he will have English lip motion.
>
>  The above isn't assuming that the content is being created 
> explicitly to accommodate deaf people. If the goal is specifically 
> to focus on that then some different policies might help.

Since the context of the draft is interactive real-time media, and 
since we want to keep the draft as simple as possible, we're probably 
better off not getting into lip sync.  We can just avoid mention, and 
it can be added in later work.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Hospitals are Sued by 7 Foot Doctors
--Newspaper headline


From nobody Tue Nov 21 14:02: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 77DD91275AB for ; Tue, 21 Nov 2017 14:01:55 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZNumCN-W4VXP for ; Tue, 21 Nov 2017 14:01:52 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 411E31270AB for ; Tue, 21 Nov 2017 14:01:52 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 21 Nov 2017 14:01:58 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <21a8709d-87f1-e1e4-10cf-340e6b7e43ce@omnitor.se>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <21a8709d-87f1-e1e4-10cf-340e6b7e43ce@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 21 Nov 2017 14:01:47 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Bernard Aboba 
From: Randall Gellens 
Cc: slim@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 22:01:59 -0000

I noticed that in the reply that Gunnar copied,=20
Addison says "it is really useful to say "give me=20
all of the 'en-US' content you have" or "do you=20
have content for a user who speaks 'es' ".  Such=20
uses are outside the scope of the document.  I=20
also note that the comment was against wording=20
that has since been deleted.

--Randall

At 10:07 PM +0100 11/21/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-11-21 kl. 16:59, skrev Bernard Aboba:
>
>>  [BA] LGTM.  Do you recall what the objection=20
>> was to the term "spoken/written language"?
>>
>   It was in this mail in the archive:
>=20
> https://=
www.ietf.org/mail-archive/web/slim/current/msg00744.html
>
>  It is Addison commenting on proposals for=20
> section 5.4, and specifically commenting on=20
> this proposed point:
>
>   >>>  2.    Text captions included in the video stream SHALL be indicated
>>>>  by a Language-Tag for spoken/written language.
>
>  And the comment from Addison was:
>
>  "I'm not sure what #2 really means. Shouldn't=20
> text captions be indicated by the written=20
> language
>  rather than the spoken language? And I'm not=20
> sure what "spoken/written language" means. "
>
>  My answer next day on this point was:
>
>  "
>  #2 was: "
>
>  2.    Text captions included in the video stream SHALL be indicated
>  by a Language-Tag for spoken/written language."
>
>  Yes, the intention is to use written language=20
> in the video stream. There are technologies for=20
> that. Since the language subtags in the IANA=20
> registry are combined for spoken languages and=20
> written languages, I call them Language-Tags=20
> for spoken/written language. It would be=20
> misleading to say that we use a Language-Tag=20
> for a writtenlanguage, because the same tag=20
> could in another context mean a=20
> spoken language. Since we have the script=20
> subtag Zxxx for non-written, we do not need=20
> to construct an explicit tag for the written=20
> language tag, it should be sufficient with our=20
> specification of the use in our case.In my=20
> latest recent proposal, I still have a very=20
> similar wording. Since you had problems=20
> understanding it, there might still be a need=20
> to tune it. Can you propose wording?This is the=20
> current
>   proposal:
>
>  "   2.    Text captions included in the video stream SHOULD be indicated
>    by a humintlang attribute with Language-Tag for spoken/written language=
=2E
>  "
>  Addison responded in=20
> https://=
www.ietf.org/mail-archive/web/slim/current/msg00757.html
>
>>  Yes, the intention is to use written language in the video stream. There=
 are
>>  technologies for that.
>
>  I'm aware of that. My concern is that in this=20
> case "spoken/written" is applied to "text=20
> captions", which are not spoken be definition?=20
> This section is talking about the differences=20
> between identifying spoken and written=20
> language. The text captions fall into the=20
> written side of the equation, no?
>
>  I'd probably prefer to see something like
>  "2. Text captions included in the video stream=20
> SHOULD include a Language-Tag to identify the=20
> language."
>
>>  Since the language subtags in the IANA registry are combined for spoken
>>  languages and written languages, I call them=20
>> Language-Tags for spoken/written
>>  language.
>
>  The language subtags are for languages--all modalities. My comment here
>  is that "spoken/written" adds no information.
>
>>  It would be misleading to say that we use a Language-Tag for a written
>>  language, because the same tag could in another context mean a spoken
>>  language.
>
>  One uses a Language-Tag for indicating the=20
> language. When the text is written,
>  sometimes the user will pick a different language tag (zh-Hant-HK) than t=
hey
>  might choose for spoken text (yue-HK, zh-cmn-HK, etc.). Sometimes (actual=
ly,
>  nearly all the time except for special cases) the language tag for the sp=
oken
>  and written language is the same tag (en-US, de-CH, ja-JP, etc.). Again, =
the
>  modality of the language is a separate consideration from the language.
>  Nearly always, it is better to use the same tag for both spoken and writt=
en
>  content rather than trying to use the tag to distinguish between them:
>  different Content-Types require different decoders anyway, but it is real=
ly
>  useful to say "give me all of the 'en-US' content you have" or "do you ha=
ve
>   content for a user who speaks 'es'"
>
>   The result was that we modified text in a few places where we had us=
ed
>  "spoken/written language tag".
>
>  Now, the term has reappeared, and I assume that the language experts stil=
l
>  have the same concerns as in February.
>
>  When we use the term, it is intended to mean "tag for non-signed language=
".
>  Therefore it is not appropriate to just replace it with "Language tag"
>  and we need to decide what to do. Shall we define what we mean with
>  "spoken/written language tag" or try to reword=20
> the sentences containing that term?
>
>
>
>  Gunnar
>
>>
>>  Gunnar had said:
>>
>>  "A proposal trying to act on issues 1-4 plus other minor rewording:
>>=20
>> -------------------------------------------------------------------------=
--------------------------------------
>>  5.4 Media, Language and Modality indications
>>  A spoken/written language tag included in a=20
>> text media description is an indication for=20
>> written language. A spoken/written language=20
>> tag included in an audio media description is=20
>> an indication for spoken language. A sign=20
>> language tag included in a video media=20
>> description is an indication for sign language=20
>> in the video stream.  
>>
>>  A sign language can be identified by the=20
>> existence in the IANA registry of language=20
>> subtags according to BCP 47 [RFC5646] of the=20
>> language subtag with the Type field "extlang"=20
>> combined with the Prefix field value "sgn".  A=20
>> spoken/written language tag can be identified=20
>> by not having any such "sgn" prefix.
>>
>>  This document does not define the use of sign=20
>> language tags in text or audio media.  By=20
>> including a language tag for spoken language=20
>> in a video description and using the "lip=20
>> sync" grouping mechanism defined in [RFC5888]=20
>> it is possible to indicate synchronized audio=20
>> and video so as to support lip reading. Other=20
>> use of spoken/written language tags in a video=20
>> description (such as for video embedded text=20
>> captions) is not defined in this document.
>>
>>
>>  Use of 'hlang' attributes may appear in other=20
>> media descriptions, such as "message" and=20
>> "application" supported by further work or=20
>> application specific agreements."
>>
>>  On Tue, Nov 21, 2017 at 12:00 AM, Gunnar=20
>> Hellstr=F6m=20
>> <gunnar.hellstrom@omnitor.se>=20
>> wrote:
>>
>>  Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
>>
>>>  Can we include text from Brian's suggestion? For example:
>>
>>  "If a sign language is signaled in a video=20
>> stream, it is interpreted as an indication=20
>> that sign language will appear in the=20
>> video.  A sign language can be identified by=20
>> the existence in the IANA registry of language=20
>> subtags according to BCP 47 [RFC5646] of the=20
>> language subtag with the Type field "extlang"=20
>> combined with the Prefix field value "sgn".  A=20
>> spoken/written language tag can be identified=20
>> by not having any such "sgn" prefix. This=20
>> document does not define any other use for=20
>> language tags in video media (such as how to=20
>> indicate a desire for visible captions).
>>
>>  This document does not define the use of sign=20
>> language tags in text or audio media.  If a=20
>> spoken/written language tag is included in=20
>> text media, it indicates a desire for written=20
>> language. If a spoken/written language tag is=20
>> included in audio media, it is interpreted as=20
>> an indication that spoken language is desired.=20
>> Using the "lip sync" grouping mechanism=20
>> defined in [RFC5888], it is possible to=20
>> indicate the desire to synchronize audio and=20
>> video so as to support lip reading.
>>
>>  Use of language tags may appear in other=20
>> media, such as "message" and "application".=20
>> Such use may be supported by further work or=20
>> application specific agreement."
>>
>>  Quite good. I see four small issues.
>>  1: "WILL appear" is not right in the first=20
>> sentence. The indication may be just one of a=20
>> set of indicated languages.
>>  2: The first paragraph says that we do not=20
>> define other use of language tags in video=20
>> than for sign language, but the second=20
>> paragraph defines how to use tags for spoken=20
>> language in video.
>>  3: I prefer to start with the three normal clearly supported cases.
>>  4: The indications sometimes indicate desire,=20
>> sometimes capability. Therefore the word=20
>> "desire" is not suitable in the explanations.
>>  5: In the LC review, we had some resistance=20
>> against using the term "spoken/written=20
>> language tag". It appears again in the=20
>> proposal. I do not understand the resistance=20
>> and I do not know how strict it was, but we=20
>> need to know if it is ok to use that term.  (I=20
>> do not change that for now in the proposal=20
>> below.)
>>
>>
>>  A proposal trying to act on issues 1-4 plus other minor rewording:
>>=20
>> -------------------------------------------------------------------------=
--------------------------------------
>>  5.4 Media, Language and Modality indications
>>  A spoken/written language tag included in a=20
>> text media description is an indication for=20
>> written language. A spoken/written language=20
>> tag included in an audio media description is=20
>> an indication for spoken language. A sign=20
>> language tag included in a video media=20
>> description is an indication for sign language=20
>> in the video stream. 
>>
>>  A sign language can be identified by the=20
>> existence in the IANA registry of language=20
>> subtags according to BCP 47 [RFC5646] of the=20
>> language subtag with the Type field "extlang"=20
>> combined with the Prefix field value "sgn".  A=20
>> spoken/written language tag can be identified=20
>> by not having any such "sgn" prefix.
>>
>>  This document does not define the use of sign=20
>> language tags in text or audio media.  By=20
>> including a language tag for spoken language=20
>> in a video description and using the "lip=20
>> sync" grouping mechanism defined in [RFC5888]=20
>> it is possible to indicate synchronized audio=20
>> and video so as to support lip reading. Other=20
>> use of spoken/written language tags in a video=20
>> description (such as for video embedded text=20
>> captions) is not defined in this document.
>>
>>
>>  Use of 'hlang' attributes may appear in other=20
>> media descriptions, such as "message" and=20
>> "application" supported by further work or=20
>> application specific agreements.
>>
>>  ------------------------------------------------------------------
>>
>>
>>>
>>
>>
>>  On Mon, Nov 20, 2017 at 1:14 PM, Gunnar=20
>> Hellstr=F6m=20
>> <gunnar.hellstrom@omnitor.se>=20
>> wrote:
>>
>>  A new proposal for new text taking in latest=20
>> discussion of Bernard, Paul and Brian:
>>
>>  -----Old text----
>>
>>  5.4 Undefined Combinations
>>
>>
>>
>>     The behavior when specifying a non-signed language tag for a video
>>     media stream, or a signed language tag for an audio or text media
>>     stream, is not defined in this document.
>>
>>     The problem of knowing which language tags are signed and which are
>>     not is out of scope of this document.
>>   -----New text------------
>>  5.4 Media, Language and Modality indications
>>
>>  The combination of Language tags and other=20
>> information in the media descriptions shall be=20
>> composed so that the intended modality can be=20
>> concluded by the negotiating parties. The=20
>> following combinations of language tags and=20
>> media provide obvious information about the=20
>> modality: sign language tags in video media=20
>> indicate signed modality, language tags in=20
>> audio media indicate spoken modality and=20
>> language tags in text media indicate written=20
>> modality. The examples in this specification=20
>> are all from this set of three obvious=20
>> language/media/modality combinations.
>>
>>  A sign language can be identified by the=20
>> existence in the IANA registry of language=20
>> subtags according to BCP 47 [RFC5646] of the=20
>> language subtag with the Type field "extlang"=20
>> combined with the Prefix field value "sgn".
>>  A specific spoken or written language can be=20
>> identified by not having any such "sgn" Prefix.
>>
>>  Use of language may appear in other media,=20
>> such as "message" and "application". Video=20
>> media may be used for other modalities than=20
>> signed, e.g. a view of a speaker or text=20
>> captions. Such use may be supported by further=20
>> work or application specific agreements for=20
>> evaluation of the intended modality.
>>
>>  ---------------------------End of new=20
>> text---------------------------------------
>>
>>
>>  Den 2017-11-20 kl. 21:44, skrev Gunnar Hellstr=F6m:
>>
>>>  Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>>>
>>>>  Gunnar said:
>>>
>>>  "5.4 Media, Language and Modality indications
>>>
>>>  The combination of Language tags and other=20
>>> information in the media descriptions should=20
>>> be composed so that the intended modality can=20
>>> be concluded by the negotiating parties. "
>>>
>>>  [BA] Is the "should" intended to be normative?
>>>
>>  You are right that SHOULD should be=20
>> avoided and it would be better to say MUST if=20
>> we can. But I can imagine limited area=20
>> applications having application agreements=20
>> e.g. saying that a non-signed language tag in=20
>> video media means a view of a talking person.=20
>> The negotiating applications know about this=20
>> agreement so they can make the conclusion. So,=20
>> if such situations can be included in how the=20
>> parties make their conclusions, we can change=20
>> to MUST. 
>>
>>>
>>  The following combinations of language tags=20
>> and media provide obvious information about=20
>> the modality: sign language tags in video=20
>> media indicate signed modality... A sign=20
>> language can be identified by the existence in=20
>> the IANA registry of language subtags=20
>> according to BCP 47 [RFC5646] of the language=20
>> subtag with the Type field "extlang" combined=20
>> with the Prefix field value "sgn".  A specific=20
>> spoken or written language can be identified=20
>> by not having any such "sgn" Prefix.
>>
>>  Use of language may appear in other media,=20
>> such as "message" and "application". Video=20
>> media may be used for other modalities than=20
>> signed. Such use may be supported by further=20
>> work or application specific agreements or=20
>> indications for evaluation of the intended=20
>> modality. "
>>
>>
>>  [BA] Assume we can confirm the mechanism for=20
>> distinguishing signed/non-signed languages,=20
>> this part seems relatively solid.
>>
>>  spoken language tags for audio media indicate=20
>> spoken modality and written language tags for=20
>> text media indicate written modality. The=20
>> examples in this specification are all from=20
>> this set of three obvious=20
>> language/media/modality combinations.
>>
>>  [BA]  This is where the ground gets less solid=20
>> - we don't really have a general mechanism for=20
>> distinguishing spoken and written modality=20
>> among non-signed languages. Perhaps we should=20
>> just say "language tags in audio media=20
>> indicate spoken modality and language tags in=20
>> text media indicate written modality".
>>
>>  Yes, right, that is better wording.
>>
>>  Gunnar
>>
>>>
>>>
>>>
>>
>>
>>  On Mon, Nov 20, 2017 at 9:25 AM, Gunnar=20
>> Hellstr=F6m=20
>> <gunnar.hellstrom@omnitor.se>=20
>> wrote:
>>
>>  It is not the signed languages that are=20
>> causing the problem. It is the spoken and=20
>> written, when used in other media than the=20
>> obvious audio and text media.
>>
>>  And we should specify what is obvious and well=20
>> defined and not, so here is a new shorter=20
>> proposal for section 5.4.
>>
>>  -----Old text----
>>
>>  5.4 Undefined Combinations
>>
>>
>>
>>     The behavior when specifying a non-signed language tag for a video
>>     media stream, or a signed language tag for an audio or text media
>>     stream, is not defined in this document.
>>
>>     The problem of knowing which language tags are signed and which are
>>     not is out of scope of this document.
>>   -----New text------------
>>  5.4 Media, Language and Modality indications
>>
>>  The combination of Language tags and other=20
>> information in the media descriptions should=20
>> be composed so that the intended modality can=20
>> be concluded by the negotiating parties. The=20
>> following combinations of language tags and=20
>> media provide obvious information about the=20
>> modality: sign language tags in video media=20
>> indicate signed modality, spoken language tags=20
>> for audio media indicate spoken modality and=20
>> written language tags for text media indicate=20
>> written modality. The examples in this=20
>> specification are all from this set of three=20
>> obvious language/media/modality combinations.
>>
>>  A sign language can be identified by the=20
>> existence in the IANA registry of language=20
>> subtags according to BCP 47 [RFC5646] of the=20
>> language subtag with the Type field "extlang"=20
>> combined with the Prefix field value "sgn".
>>  A specific spoken or written language can be=20
>> identified by not having any such "sgn" Prefix.
>>
>>  Use of language may appear in other media,=20
>> such as "message" and "application". Video=20
>> media may be used for other modalities than=20
>> signed. Such use may be supported by further=20
>> work or application specific agreements or=20
>> indications for evaluation of the intended=20
>> modality.
>>
>>=20
>> -------------------------------------------------------------------End=20
>> of new=20
>> text---------------------------------------
>>
>>  Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>
>>>  At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>
>>>>   "So let's delete Section 5.4 and be done=20
>>>> with it.  Neither of the statements is=20
>>>> necessary."
>>>>
>>>>   [BA]  I agree that Section 5.4 does not add much value as it stands.
>>>>
>>>>   "Non-signed" is not used outside of Section=20
>>>> 5.4, so there would not appear to be a need=20
>>>> to define it if Section 5.4 were to be=20
>>>> deleted.
>>>>
>>>>   However, the term "signed" is used in 7=20
>>>> other places in the document other than in=20
>>>> Section 5.4.
>>>>
>>
>>  But none of those instances are normative.
>>
>>>   So we may need to find a reference to define that term.
>>>
>>
>>  Because the uses of the term are descriptive=20
>> and mostly background, I do not think we need=20
>> to add a definition or even a reference to a=20
>> definition of the term.
>>
>>  --Randall
>>
>>>
>>>   If Gunnar's suggested definition can be=20
>>> confirmed,  this might be as simple as adding=20
>>> a reference to the IANA language tag=20
>>> repository.
>>>
>>>   On Sun, Nov 19, 2017 at 3:52 PM, Randall=20
>>> Gellens=20
>>> <rg+ietf@randy.pensive.org>=20
>>> wrote:
>>>
>>>   My view of issue #43 remains that we do not=20
>>> need to specify a mechanism for determining=20
>>> which tags are signed.  In the email=20
>>> discussion of the past month or so, I fear we=20
>>> are drifting into adding complexity rather=20
>>> than removing it.  I think the way forward is=20
>>> to keep this document as simple as possible.=20
>>> As Bernard notes in his email of 10/23, there=20
>>> is no benefit in this case of explicitly=20
>>> saying that certain things are not defined.=20
>>> Since the document does not define them, they=20
>>> are undefined in the document.
>>>
>>>   At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>
>>>    In other words,it is not clear to me how=20
>>> Section 5.4's discussion of scope improves or=20
>>> clarifies the situation in any way - and=20
>>> there is some possibility that it could cause=20
>>> problems.
>>>
>>>
>>>
>>>   I believe comment #43 should be closed as no=20
>>> longer applicable, since the text against=20
>>> which it was generated has been deleted.=20
>>> (I've said this before, and I believe it=20
>>> remains the case.)
>>>
>>>   The comment from which #43 derives was made=20
>>> against a version of the document that had=20
>>> text explicitly discussing signed versus=20
>>> unsigned tags.  That text was subsequently=20
>>> deleted.
>>>
>>>   Here is the comment from which #43 derived:
>>>
>>>       5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>>>
>>>       Note that while signed language tags are used with a video stream
>>>    to
>>>       indicate sign language, a spoken language tag for a video stream
>>>    in
>>>       parallel with an audio stream with the same spoken language tag
>>>       indicates a request for a supplemental video stream to see the
>>>       speaker.
>>>
>>>    And there's a similar paragraph in 5.4:
>>>
>>>       A spoken language tag for a video stream in conjunction with an
>>>
>>>    audio
>>>
>>>       stream with the same language might indicate a request for
>>>       supplemental video to see the speaker.
>>>
>>>
>>>    I think this mechanism needs to be described more exactly, and in
>>>    particular, it should not depend on the UA understanding which
>>>    language tags are spoken language tags.  It seems to me that a
>>>    workable rule is that there is an audio stream and a video stream and
>>>    they specify exactly the same language tag in their respective
>>>    humintlang attributes.  In that case, it is a request for a spoken
>>>    language with simultaneous video of the speaker, and those requests
>>>    should be considered satisfied only if both streams can be
>>>    established.
>>>
>>>
>>>   The offending text that was in 5.2 and 5.4 was deleted.
>>>
>>>   The only remaining text that even mentions the issue is Section 5.4:
>>>
>>>      The behavior when specifying a non-signed language tag for a video
>>>      media stream, or a signed language tag for an audio or text media
>>>      stream, is not defined in this document.
>>>
>>>      The problem of knowing which language tags are signed and which are
>>>      not is out of scope of this document.
>>>
>>>   So, let's delete Section 5.4 and be done=20
>>> with it.  Neither of the statements is=20
>>> necessary.
>>>
>>>   --
>>>   Randall Gellens
>>>   Opinions are personal;    facts are suspect;    I speak for myself onl=
y
>>>   -------------- Randomly selected tag: ---------------
>>>   Make it right before you make it faster.
>>>
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  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
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellstr=F6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Premature optimization is the root of all evil
                              --C. A. R. Hoare


From nobody Tue Nov 21 14:05: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 29FBE129BDA for ; Tue, 21 Nov 2017 14:05:46 -0800 (PST)
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 8ZQLX_PvvH3U for ; Tue, 21 Nov 2017 14:05:44 -0800 (PST)
Received: from bin-vsp-out-01.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 12679129B52 for ; Tue, 21 Nov 2017 14:05:43 -0800 (PST)
X-Halon-ID: 14b7d76b-cf08-11e7-aaf4-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 14b7d76b-cf08-11e7-aaf4-005056917a89; Tue, 21 Nov 2017 23:05:28 +0100 (CET)
To: Paul Kyzivat , slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>   <4efeeff4-bcd7-661e-93c9-23e6fec3704b@alum.mit.edu>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <7bb1e6dd-f926-56d5-2c7c-082563b3de95@omnitor.se>
Date: Tue, 21 Nov 2017 23:05:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4efeeff4-bcd7-661e-93c9-23e6fec3704b@alum.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 21 Nov 2017 22:05:46 -0000

Den 2017-11-21 kl. 21:53, skrev Paul Kyzivat:
> On 11/21/17 2:45 PM, Gunnar Hellström wrote:
>> Den 2017-11-21 kl. 18:06, skrev Bernard Aboba:
>>> Paul said:
>>>
>>> "When using lip sync, is there any necessity to put the language tag 
>>> on the video?"
>>>
>>> [BA] Good point.
>>>
>>> "   By including a language tag for spoken language in an audio
>>>    description and using the "lip sync" grouping mechanism defined
>>>    in [RFC5888] to group it with a video media stream it is possible
>>>    to indicate synchronized audio and video so as to support lip
>>>  reading."
>>>
>>> [BA] This seems like an improvement.
>> I do not think that an indication of lip reading synch grouping 
>> can be assumed to mean that the user promises to be seen in video. I 
>> guess that most products implementing the lip synch grouping do it 
>> generally for all calls regardless of if the user want to provide or 
>> see lips in synch.
>
> I wonder if they do it even when it isn't true.
 The purpose of our protocol is to be used for conversational 
services. i.e. real-time calls. And for them, I just assume that if the 
manufacturer of the device has taken the effort to implement RFC 5888 
Lip Sync, it is a technical feature that is active in all calls of the 
device regardless of how the users intend to use the media. All users 
appreciate good sync, so if the device is capable of providing good sync 
without sacrificing other factors too much, it will be used.
It is not really realistic to turn Lip Sync on or off depending on the 
language preference settings.

>
>
> For instance, consider a movie that was created in English. So the 
> actors are speaking English, the audio is labeled as English, and 
> there is lip sync.
>
> Now take the same movie and dub it in Spanish. Now the audio ought to 
> be labeled as Spanish. But lip sync should no longer be indicated. Is 
> that what happens in practice?
The example is from streamed application. I think lip sync will be 
activated anyway if the streaming service supports it. RFC 5888 is not 
meant to just handle the real lip sync usage, it is to indicate when 
good sync can be supported technically. RFC 5888 says: "Note that LS 
semantics apply not only to a video stream that has to be synchronized 
with an audio stream; the playout of two streams of the same type can be 
synchronized as well." That clearly indicates that it is not intended 
for just the lip sync use.
>
> Of course, a totally deaf English speaking lip reader will understand 
> both equally well. But there may not be anything in the signaling to 
> indicate that he will have English lip motion.
Right, that is a good reason for keeping the spoken language tag in 
the video description, and not requiring the same language to appear in 
the audio media description.

So, as a summary, I am afraid that the good idea of using RFC 5888 Lip 
Sync as an indication that we mean a view of a speaking person in video 
has similar bad side effects as my cancelled proposal to use the 
"speaker" in an SDP Content attribute according to RFC 4796 [RFC4796] 
for the same purpose. What is left to do for now is to not define any 
way to indicate language of captions in the video stream but use 
spoken/written language tags in video as an indication to view a 
speaker. This is also supported by Randalls observation that captions in 
video is hardly used in conversational calls.

I will create a new 5.4 proposal in another mail.

Gunnar

>
> The above isn't assuming that the content is being created explicitly 
> to accommodate deaf people. If the goal is specifically to focus on 
> that then some different policies might help.


>
>     Thanks,
>     Paul
>
>> But it is a good feature to use if you desire to see a speaker.
>> The 'hlang' attribute in a video description is on the other hand 
>> clear indications that you want to provide or receive language in the 
>> video media stream.
>> Therefore I think we should return either to say that a 
>> spoken/written language tag in video media description means a view 
>> of the speaker if there is also a lip synch grouping, or even skip 
>> the dependency on lip synch grouping.  (there is a risk that we 
>> introduce tricky corner cases by the bundling of lip synch and 
>> language use. How about if we by further work agree on a way to 
>> indicate written captions in MPEG4 video, and want to indicate that 
>> in a product that always provides lip synch grouping. That will cause 
>> conflicts.)
>>
>> Randall recently commented that use of text captions in the video 
>> stream is a far fetched use case. MPEG4 has caption elements defined 
>> and it can be provided in media declared as video, but it may be 
>> right that it is rarely or never used in conversational calls. If we 
>> can agree on that we could simply return to saying that a 
>> spoken/written language tag in video description means a view of a 
>> speaker, and skip the requirement to link it to the language in the 
>> audio stream.
>>
>> Gunnar
>>>
>>> On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat >> > wrote:
>>>
>>>     On 11/21/17 10:59 AM, Bernard Aboba wrote:
>>>
>>>         [BA] LGTM.  Do you recall what the objection was to the term
>>>         "spoken/written language"?
>>>
>>>         Gunnar had said:
>>>
>>>         By including a language tag for spoken language in a video
>>>         description and using the "lip sync" grouping mechanism
>>>         defined in [RFC5888] it is possible to indicate synchronized
>>>         audio and video so as to support lip reading.
>>>
>>>
>>>     When using lip sync, is there any necessity to put the language
>>>     tag on the video? ISTM that is irrelevant, as long as it is on the
>>>     synced audio media. ISTM it would be better to say:
>>>
>>>        By including a language tag for spoken language in an audio
>>>        description and using the "lip sync" grouping mechanism defined
>>>        in [RFC5888] to group it with a video media stream it is 
>>> possible
>>>        to indicate synchronized audio and video so as to support lip
>>>        reading.
>>>
>>>             Thanks,
>>>             Paul
>>>
>>>
>>>     _______________________________________________
>>>     SLIM mailing list
>>>     SLIM@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/slim
>>>     
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>>
>> _______________________________________________
>> SLIM mailing list
>> SLIM@ietf.org
>> https://www.ietf.org/mailman/listinfo/slim
>>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Tue Nov 21 14:50: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 A61A912960D for ; Tue, 21 Nov 2017 14:50:27 -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 M4Kwj5YnsXUA for ; Tue, 21 Nov 2017 14:50:26 -0800 (PST)
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 A8FD6126B6E for ; Tue, 21 Nov 2017 14:50:25 -0800 (PST)
X-Halon-ID: 52462141-cf0e-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 52462141-cf0e-11e7-96ae-005056917f90; Tue, 21 Nov 2017 23:50:09 +0100 (CET)
To: Randall Gellens , Brian Rosen , Bernard Aboba , Paul Kyzivat 
Cc: slim@ietf.org
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>   
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>
Date: Tue, 21 Nov 2017 23:50:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FAAE0AFF40D72FFF4705D6B9"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 21 Nov 2017 22:50:27 -0000

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

Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
> Based on the text and comments from Gunnar, brian, Paul, and Bernard, 
> here is what I propose to replace section 5.4 with:
>
> 5.4. Usage Notes
>
>  A sign language tag with a video stream is interpreted as an
>  indication for sign language in the video stream. A non-sign
>  language tag with text media is interpreted as an indication for
>  written language. A non-sign language tag with audio media is
>  interpreted as an indication for spoken language.
>
>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>  language subtag with a Type field "extlang" combined with a Prefix
>  field value "sgn" indicates a sign language tag. The absense of
>  such "sgn" prefix indicates a non-sign language tag. This document
>  does not define any other use for language tags in video media
>  (such as how to indicate visible captions).
>
>  This document does not define the use of sign language tags in text
>  or audio media.
>
>  This document does not define the use of language tags in media
>  other than interactive streams of audio, video, and text (such as
>  "message" or "application").
 Good, I hope that "non-sign language" can be an accepted term.
I provide a slightly modified 5.4 proposal, with a bit more consistent 
language in the first paragraph, and the mentioning of further work or 
application agreement reinserted. I think that is better than just 
saying that it is not defined. I also added the spoken language in video 
is a view of a speaker according to recent discussion in another mail.
I really hope to find that we are converging now.

------------------------------new text 
-------------------------------------------
5.4 Media, Language and Modality indications

  A sign language tag with video media is interpreted as an
  indication for sign language in the video stream. A non-sign
  language tag with text media is interpreted as an indication for
  written language. A non-sign language tag with audio media is
  interpreted as an indication for spoken language. A non-sign
  language tag with video media is interpreted as a view of a
  speaking person. This document does not define any other
  use for language tags in video media (such as how to indicate
  visible captions in the video stream).

  In the IANA registry of language subtags per BCP 47 [RFC5646], a
  language subtag with a Type field "extlang" combined with a Prefix
  field value "sgn" indicates a sign language tag. The absense of
  such "sgn" prefix indicates a non-sign language tag.

  This document does not define the use of sign language tags in text
  or audio media. This document does not define the use of language 
tags in media
  other than interactive streams of audio, video, and text (such as
  "message" or "application"). Such use may be supported by further work
  or application specific agreements.

---------------------------------------------------------------------------------------------
Gunnar

-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288


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


  
    
  
  
    Den 2017-11-21 kl. 23:08, skrev Randall Gellens:

    
Based on the text
      and comments from Gunnar, brian, Paul, and Bernard, here is what I
      propose to replace section 5.4 with:
      

      

      5.4. Usage Notes
      

      

       A sign language tag with a video stream is interpreted as an
      

       indication for sign language in the video stream. A non-sign
      

       language tag with text media is interpreted as an indication
      for
      

       written language. A non-sign language tag with audio media is
      

       interpreted as an indication for spoken language.
      

      

       In the IANA registry of language subtags per BCP 47 [RFC5646],
      a
      

       language subtag with a Type field "extlang" combined with a
      Prefix
      

       field value "sgn" indicates a sign language tag. The absense
      of
      

       such "sgn" prefix indicates a non-sign language tag. This
      document
      

       does not define any other use for language tags in video media
      

       (such as how to indicate visible captions).
      

      

       This document does not define the use of sign language tags in
      text
      

       or audio media.
      

      

       This document does not define the use of language tags in media
      

       other than interactive streams of audio, video, and text (such
      as
      

       "message" or "application").
      

    

    <GH> Good, I hope that "non-sign language" can be an accepted
    term. 

    I provide a slightly modified 5.4 proposal, with a bit more
    consistent language in the first paragraph, and the mentioning of
    further work or application agreement reinserted. I think that is
    better than just saying that it is not defined. I also added the
    spoken language in video is a view of a speaker according to recent
    discussion in another mail. 

    I really hope to find that we are converging now.

    

    ------------------------------new text
    -------------------------------------------

    5.4 Media, Language and Modality indications

    

     A sign language tag with video media is interpreted as an
    

     indication for sign language in the video stream. A non-sign
    

     language tag with text media is interpreted as an indication for
    

     written language. A non-sign language tag with audio media is
    

     interpreted as an indication for spoken language.
    A non-sign 

     language tag with video media is interpreted as a view of a 

     speaking person. This document
    does not define any other 

     use for language tags in video media
    (such as how to indicate 

     visible captions in the video stream).
    

    

     In the IANA registry of language subtags per BCP 47 [RFC5646], a
    

     language subtag with a Type field "extlang" combined with a
    Prefix
    

     field value "sgn" indicates a sign language tag. The absense of
    

     such "sgn" prefix indicates a non-sign language tag. 

    

     This document does not define the use of sign language tags in
    text
    

     or audio media.
    This document does not define the use of language tags in media
    

     other than interactive streams of audio, video, and text (such as
    

     "message" or "application"). Such use may
    be supported by further work 

     or application specific agreements.

    

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

    Gunnar

    
-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  


--------------FAAE0AFF40D72FFF4705D6B9--


From nobody Tue Nov 21 15:10: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 2787D129BD7 for ; Tue, 21 Nov 2017 15:10:02 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 H6yE4hyF7zqk for ; Tue, 21 Nov 2017 15:10:01 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3492C1241F5 for ; Tue, 21 Nov 2017 15:10:01 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 21 Nov 2017 14:08:52 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <002bffe3-429d-f4c8-f965-d49fcc1ca590@omnitor.se> <48a8764f-ebf3-0e62-eb1a-390347d41263@alum.mit.edu>   <3ad59ba4-4bc4-e174-e67e-c7fba70ca108@omnitor.se> <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>   <002bffe3-429d-f4c8-f965-d49fcc1ca590@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>  <48a8764f-ebf3-0e62-eb1a-390347d41263@alum.mit.edu>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>        <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>  <48a8764f-ebf3-0e62-eb1a-390347d41263@alum.mit.edu> <3ad59ba4-4bc4-e174-e67e-c7fba70ca108@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>  
X-Mailer: Eudora for Mac OS X
Date: Tue, 21 Nov 2017 14:08:43 -0800
To: Brian Rosen , Bernard Aboba ,  Paul Kyzivat , =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
From: Randall Gellens 
Cc: slim@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: [Slim] Proposed 5.4 text
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, 21 Nov 2017 23:10:02 -0000

Based on the text and comments from Gunnar, brian, Paul, and Bernard, 
here is what I propose to replace section 5.4 with:

5.4.  Usage Notes

    A sign language tag with a video stream is interpreted as an
    indication for sign language in the video stream.  A non-sign
    language tag with text media is interpreted as an indication for
    written language.  A non-sign language tag with audio media is
    interpreted as an indication for spoken language.

    In the IANA registry of language subtags per BCP 47 [RFC5646], a
    language subtag with a Type field "extlang" combined with a Prefix
    field value "sgn" indicates a sign language tag.  The absense of
    such "sgn" prefix indicates a non-sign language tag.  This document
    does not define any other use for language tags in video media
    (such as how to indicate visible captions).

    This document does not define the use of sign language tags in text
    or audio media.

    This document does not define the use of language tags in media
    other than interactive streams of audio, video, and text (such as
    "message" or "application").

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville


From nobody Tue Nov 21 15:17:36 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 D772312704A for ; Tue, 21 Nov 2017 15:17:34 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nZIBHx6qZ_xP for ; Tue, 21 Nov 2017 15:17:33 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 109A81241F5 for ; Tue, 21 Nov 2017 15:17:33 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 21 Nov 2017 15:17:39 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 21 Nov 2017 15:17:30 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Brian Rosen , Bernard Aboba , Paul Kyzivat 
From: Randall Gellens 
Cc: slim@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 21 Nov 2017 23:17:35 -0000

I agree.  I made a few minor editorial changes=20
(e.g., moving some text to a new paragraph):

5.4.  Usage Notes

    A sign language tag with a video media stream is interpreted as an
    indication for sign language in the video stream.  A non-sign
    language tag with a text media stream is interpreted as an
    indication for written language in the text stream.  A non-sign
    language tag with an audio media stream is interpreted as an
    indication for spoken language in the audio stream.

    This document does not define any other use for language tags in
    video media (such as how to indicate visible captions in the video
    stream).

    In the IANA registry of language subtags per BCP 47 [RFC5646], a
    language subtag with a Type field "extlang" combined with a Prefix
    field value "sgn" indicates a sign language tag.  The absense of
    such "sgn" prefix indicates a non-sign language tag.

    This document does not define the use of sign language tags in text
    or audio media.

    This document does not define the use of language tags in media
    other than interactive streams of audio, video, and text (such as
    "message" or "application").  Such use could be supported by future
    work or by application agreement.

At 11:50 PM +0100 11/21/17, Gunnar Hellstr=F6m wrote:

>  Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
>
>>  Based on the text and comments from Gunnar,=20
>> brian, Paul, and Bernard, here is what I=20
>> propose to replace section 5.4 with:
>>
>>  5.4. Usage Notes
>>
>>  A sign language tag with a video stream is interpreted as an
>>  indication for sign language in the video stream. A non-sign
>>  language tag with text media is interpreted as an indication for
>>  written language. A non-sign language tag with audio media is
>>  interpreted as an indication for spoken language.
>>
>>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>>  language subtag with a Type field "extlang" combined with a Prefix
>>  field value "sgn" indicates a sign language tag. The absense of
>>  such "sgn" prefix indicates a non-sign language tag. This document
>>  does not define any other use for language tags in video media
>>  (such as how to indicate visible captions).
>>
>>  This document does not define the use of sign language tags in text
>>  or audio media.
>>
>>  This document does not define the use of language tags in media
>>  other than interactive streams of audio, video, and text (such as
>>  "message" or "application").
>>
>   Good, I hope that "non-sign language" can be an accepted term.
>  I provide a slightly modified 5.4 proposal,=20
> with a bit more consistent language in the=20
> first paragraph, and the mentioning of further=20
> work or application agreement reinserted. I=20
> think that is better than just saying that it=20
> is not defined. I also added the spoken=20
> language in video is a view of a speaker=20
> according to recent discussion in another mail.
>  I really hope to find that we are converging now.
>
>  ------------------------------new text=20
> -------------------------------------------
>  5.4 Media, Language and Modality indications
>
>  A sign language tag with video media is interpreted as an
>  indication for sign language in the video stream. A non-sign
>  language tag with text media is interpreted as an indication for
>  written language. A non-sign language tag with audio media is
>  interpreted as an indication for spoken language. A non-sign
>  language tag with video media is interpreted as a view of a
>  speaking person. This document does not define any other
>  use for language tags in video media (such as how to indicate
>  visible captions in the video stream).
>
>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>  language subtag with a Type field "extlang" combined with a Prefix
>  field value "sgn" indicates a sign language tag. The absense of
>  such "sgn" prefix indicates a non-sign language tag.
>
>  This document does not define the use of sign language tags in text
>  or audio media. This document does not define=20
> the use of language tags in media
>  other than interactive streams of audio, video, and text (such as
>  "message" or "application"). Such use may be supported by further work
>  or application specific agreements.
>
>=20
> --------------------------------------------------------------------------=
-------------------
>  Gunnar
>  --
>  -----------------------------------------
>  Gunnar Hellstr=F6m
>  Omnitor
>  gunnar.hellstrom@omnitor.se
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  SLIM@ietf.org
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never knock the way the other cat swings.
                          --Neal Cassady


From nobody Tue Nov 21 16:20:24 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 1F10B129C00 for ; Tue, 21 Nov 2017 16:20:19 -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, 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 6yzmB9oLPfQb for ; Tue, 21 Nov 2017 16:20:15 -0800 (PST)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72FF129493 for ; Tue, 21 Nov 2017 16:20:15 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id o145so8806866vkd.0 for ; Tue, 21 Nov 2017 16:20:15 -0800 (PST)
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=+DzuxBdLA3n9fJafjBDbSqTIDSB6Amp7hiFzUPC5PIQ=; b=Bz7lZzHvPRsC68wTTeRODibXPi1UZrg0lHW5Ny+TFG742K8gUpAbq5DdRfauLOaXhG hwkKUDG4DagTJVnII1wpk+HJ2z/DOSFyjC92lTfTbn6wzCs9x56CaNDamRjWgdgAqTkc BMs5SIQKemz3yd/4UvW3qX8ECblcPmJo9nlsMalJ2uRiA30y7qV/rvCyj81nbifI45ZR tmqcchzzqqfHUbJBHV1+NMlMqmyP5IdRapm73ykoNI7dRFHDihZDr7fjQja/uNcOptlv qBkoRgFVHssFbli6w2KW3rCNdJNukgNmTRC6VPpEGNa5JwYefqJEA5wothdXBLI/Bag6 skOg==
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=+DzuxBdLA3n9fJafjBDbSqTIDSB6Amp7hiFzUPC5PIQ=; b=tW6SQ8wzqAtUinsWfd4LH3IzWc9Rpf1RALOttMXhVd7DEt6WEsUvqWeOeaVIbzD3x3 IcWuGD0lDuF5ZHe/fRaUl5AjlcufEHJKgszFQlb5CjkOqujKwJ7k8SKPzRzWoRn/xhjM WTnv6giUfs2/zInvEz75f4n6PmB3oRmGvQLmg5HgASSb/X+tW8+hgXHq8ugs1l75Hi/z +vdflsec1/g1QEx4OPThSMyqYEy6qtuUMF6sYoXniAAIvGgxq8cm7XhteqhCWqt+c3B4 li9bapPOHoMo+wEwvMYIbbrIfKhjlBVoPDrAo7Maqbvf2l4cVnoGor0aTgb0nwUrSZuq cqEA==
X-Gm-Message-State: AJaThX6x8urhKdgfZJB9gMTxtlNKEgmnAjc8S2W19yl/azwa1BjPyGZX m6F90s06HpSXdoycS8GczJrEKcCs8izKGKHKtes=
X-Google-Smtp-Source: AGs4zMbHc8UQjYJ4Z02150pomckPGvmhaWgjMv7CoeLMpXJ+Q2TQ/qSZnG+eBIguKk1LlPne9FDgHHHGcP3ZEJILKv4=
X-Received: by 10.31.92.22 with SMTP id q22mr14431732vkb.10.1511310014546; Tue, 21 Nov 2017 16:20:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 16:19:53 -0800 (PST)
In-Reply-To: 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se>  <14297efe-82c5-a6d9-94f7-fe82be6b423a@alum.mit.edu>   <4efeeff4-bcd7-661e-93c9-23e6fec3704b@alum.mit.edu> 
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 16:19:53 -0800
Message-ID: 
To: Randall Gellens 
Cc: Paul Kyzivat , slim@ietf.org
Content-Type: multipart/alternative; boundary="001a114e61a2900b10055e8748d2"
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 22 Nov 2017 00:20:19 -0000

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

Randall said:

"Since the context of the draft is interactive real-time media, and since
we want to keep the draft as simple as possible, we're probably better off
not getting into lip sync.  We can just avoid mention, and it can be added
in later work."

[BA] RFC 5888 already defines how to handle lip sync negotiation in SDP.  I
think Paul's point was that that document is sufficient so that referring
to a need for "later work" is misleading.

On Tue, Nov 21, 2017 at 1:54 PM, Randall Gellens 
wrote:

> At 3:53 PM -0500 11/21/17, Paul Kyzivat wrote:
>
>  I wonder if they do it even when it isn't true.
>>
>>  For instance, consider a movie that was created in English. So the
>> actors are speaking English, the audio is labeled as English, and there is
>> lip sync.
>>
>>  Now take the same movie and dub it in Spanish. Now the audio ought to be
>> labeled as Spanish. But lip sync should no longer be indicated. Is that
>> what happens in practice?
>>
>>  Of course, a totally deaf English speaking lip reader will understand
>> both equally well. But there may not be anything in the signaling to
>> indicate that he will have English lip motion.
>>
>>  The above isn't assuming that the content is being created explicitly to
>> accommodate deaf people. If the goal is specifically to focus on that then
>> some different policies might help.
>>
>
> Since the context of the draft is interactive real-time media, and since
> we want to keep the draft as simple as possible, we're probably better off
> not getting into lip sync.  We can just avoid mention, and it can be added
> in later work.
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Hospitals are Sued by 7 Foot Doctors
> --Newspaper headline
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


Randall said:=C2=A0

"Since the context of the draft is interactive real-ti=
me media, and since we want to keep the draft as simple as possible, we'=
;re probably better off not getting into lip sync.=C2=A0 We can just avoid =
mention, and it can be added in later work."

[BA] RFC 5888 already defines how to handle lip sync negotiation in =
SDP.=C2=A0 I think Paul's point was that that document is sufficient so=
 that referring to a need for "later work" is misleading.=C2=A0

On Tue,=
 Nov 21, 2017 at 1:54 PM, Randall Gellens <rg+ietf@randy.pensive.o=
rg> wrote:
At 3:53 PM -0500 11/21/17, Paul Kyzivat wrote:





=C2=A0I wonder if they do it even when it isn't true.



=C2=A0For instance, consider a movie that was created in English. So the ac=
tors are speaking English, the audio is labeled as English, and there is li=
p sync.



=C2=A0Now take the same movie and dub it in Spanish. Now the audio ought to=
 be labeled as Spanish. But lip sync should no longer be indicated. Is that=
 what happens in practice?



=C2=A0Of course, a totally deaf English speaking lip reader will understand=
 both equally well. But there may not be anything in the signaling to indic=
ate that he will have English lip motion.



=C2=A0The above isn't assuming that the content is being created explic=
itly to accommodate deaf people. If the goal is specifically to focus on th=
at then some different policies might help.





Since the context of the draft is interactive real-time media, and since we=
 want to keep the draft as simple as possible, we're probably better of=
f not getting into lip sync.=C2=A0 We can just avoid mention, and it can be=
 added in later work.



-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

Hospitals are Sued by 7 Foot Doctors

--Newspaper headline




_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--001a114e61a2900b10055e8748d2--


From nobody Tue Nov 21 18:17:57 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 0C24C120713 for ; Tue, 21 Nov 2017 18:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 dBkcx1KYRijt for ; Tue, 21 Nov 2017 18:17:52 -0800 (PST)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557BB129C0B for ; Tue, 21 Nov 2017 18:17:52 -0800 (PST)
Received: by mail-vk0-x230.google.com with SMTP id l201so8206135vkd.1 for ; Tue, 21 Nov 2017 18:17:52 -0800 (PST)
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=M7xaQ5+D5AjCoQCs5c2AfC5Ffc32C7dAtTVoP3SC5iM=; b=RaQG1vROE2Fcj18yaWTiC5v8TZPhhuXftfzwSBEx75qtirD9hinvfE9pVjY9kd8+Dt oEhPLBGp3AnDjxxfI0Ut8npwdddi+t9w+QyIbxsOaJZAl2bn5gN/yoKzsAgpESgyLQZ0 W8N9KwHtk2b9PmMMBGVzU7l0N0bgMrnEhR0nUUpot0AkphybCePxBKWI1FyyuWyMG5+B CdQZRj2GQofSb4a8+9mSjDzG6N9OLALlH2+8eSNKjE+1TtAeeXv0VZSujPFBZaODPpQ7 YYMPL0VoG4919S03O2pMcqpOb77j8PQVneInDObaa2E2DhLVC4wujVOX69N7Cr3A5Z/d tiAw==
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=M7xaQ5+D5AjCoQCs5c2AfC5Ffc32C7dAtTVoP3SC5iM=; b=qfqehgpn8xT3bNW1KTT6+2Z8+09Mqt8ma/Nf86BcQyJ4vMprftckV7YKPFjFW3r10S KAA0SErGpBltsnhNiQvThO0432kVI7kvBicYrlADFT4OCDbT6XF8io2+5vIUMgyptEvY M78zbcdSZCoenCx3X30IUgnSYkTQ90JgqVRXmh2vdSXoRM4ZJ1oekgR7O2ur7xQxjPIH 2FRckHSxQn6zSulwNNr5qvgjocFztehWdAotWBX6bVhszqggG/0rMn9O6rqh2Bxv+j1I uwdftROB3xE861cxbobWedXYoiP1B6xc32XM/YHbkQBZaWRkyZzaL3ltIrZPubbwk1aU Jklw==
X-Gm-Message-State: AJaThX5W77FpqHTUf74fDFrc2hHwhE4C5m4WUl40XO4ivZP+9VUSqqGd +aDWM5Cnn6/cfc4tke7ssonNsEXCDsNaBgJydow=
X-Google-Smtp-Source: AGs4zMat93uaWMlsUnW522aVQnV91mYbyD4xlIyhA62VtUsmoG5Le0Eq6BohukTO5NWzEGLvxeuy6IG4xabwgZ29PDc=
X-Received: by 10.31.235.2 with SMTP id j2mr5447210vkh.57.1511317070935; Tue, 21 Nov 2017 18:17:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 18:17:30 -0800 (PST)
In-Reply-To: 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> 
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 18:17:30 -0800
Message-ID: 
To: Randall Gellens 
Cc: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= ,  Brian Rosen , Paul Kyzivat , slim@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0949d027fa88055e88ed8e"
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 02:17:55 -0000

--94eb2c0949d027fa88055e88ed8e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Looks good to me.

On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens 
wrote:

> I agree.  I made a few minor editorial changes (e.g., moving some text to
> a new paragraph):
>
> 5.4.  Usage Notes
>
>    A sign language tag with a video media stream is interpreted as an
>    indication for sign language in the video stream.  A non-sign
>    language tag with a text media stream is interpreted as an
>    indication for written language in the text stream.  A non-sign
>    language tag with an audio media stream is interpreted as an
>    indication for spoken language in the audio stream.
>
>    This document does not define any other use for language tags in
>    video media (such as how to indicate visible captions in the video
>    stream).
>
>    In the IANA registry of language subtags per BCP 47 [RFC5646], a
>    language subtag with a Type field "extlang" combined with a Prefix
>    field value "sgn" indicates a sign language tag.  The absense of
>    such "sgn" prefix indicates a non-sign language tag.
>
>    This document does not define the use of sign language tags in text
>    or audio media.
>
>    This document does not define the use of language tags in media
>    other than interactive streams of audio, video, and text (such as
>    "message" or "application").  Such use could be supported by future
>    work or by application agreement.
>
>
> At 11:50 PM +0100 11/21/17, Gunnar Hellstr=C3=B6m wrote:
>
>  Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
>>
>>  Based on the text and comments from Gunnar, brian, Paul, and Bernard,
>>> here is what I propose to replace section 5.4 with:
>>>
>>>  5.4. Usage Notes
>>>
>>>  A sign language tag with a video stream is interpreted as an
>>>  indication for sign language in the video stream. A non-sign
>>>  language tag with text media is interpreted as an indication for
>>>  written language. A non-sign language tag with audio media is
>>>  interpreted as an indication for spoken language.
>>>
>>>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>>>  language subtag with a Type field "extlang" combined with a Prefix
>>>  field value "sgn" indicates a sign language tag. The absense of
>>>  such "sgn" prefix indicates a non-sign language tag. This document
>>>  does not define any other use for language tags in video media
>>>  (such as how to indicate visible captions).
>>>
>>>  This document does not define the use of sign language tags in text
>>>  or audio media.
>>>
>>>  This document does not define the use of language tags in media
>>>  other than interactive streams of audio, video, and text (such as
>>>  "message" or "application").
>>>
>>>   Good, I hope that "non-sign language" can be an accepted term.
>>  I provide a slightly modified 5.4 proposal, with a bit more consistent
>> language in the first paragraph, and the mentioning of further work or
>> application agreement reinserted. I think that is better than just sayin=
g
>> that it is not defined. I also added the spoken language in video is a v=
iew
>> of a speaker according to recent discussion in another mail.
>>  I really hope to find that we are converging now.
>>
>>  ------------------------------new text ------------------------------
>> -------------
>>  5.4 Media, Language and Modality indications
>>
>>  A sign language tag with video media is interpreted as an
>>  indication for sign language in the video stream. A non-sign
>>  language tag with text media is interpreted as an indication for
>>  written language. A non-sign language tag with audio media is
>>  interpreted as an indication for spoken language. A non-sign
>>  language tag with video media is interpreted as a view of a
>>  speaking person. This document does not define any other
>>  use for language tags in video media (such as how to indicate
>>  visible captions in the video stream).
>>
>>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>>  language subtag with a Type field "extlang" combined with a Prefix
>>  field value "sgn" indicates a sign language tag. The absense of
>>  such "sgn" prefix indicates a non-sign language tag.
>>
>>  This document does not define the use of sign language tags in text
>>  or audio media. This document does not define the use of language tags
>> in media
>>  other than interactive streams of audio, video, and text (such as
>>  "message" or "application"). Such use may be supported by further work
>>  or application specific agreements.
>>
>>
>> ------------------------------------------------------------
>> ---------------------------------
>>  Gunnar
>>  --
>>  -----------------------------------------
>>  Gunnar Hellstr=C3=B6m
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>  +46 708 204 288
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  SLIM@ietf.org
>>  https://www.ietf.org/mailman/listinfo/slim
>>
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Never knock the way the other cat swings.
>                          --Neal Cassady
>

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


Looks good to me.=C2=A0
On Tue, Nov 21, 2017 at 3:17 PM, Randall Gelle=
ns <rg+ietf@randy.pensive.org> wrote:
I agree.=C2=A0 I made a few minor editorial changes (e.=
g., moving some text to a new paragraph):



5.4.=C2=A0 Usage Notes



=C2=A0 =C2=A0A sign language tag with a video media stream is interpreted a=
s an

=C2=A0 =C2=A0indication for sign language in the video stream.=C2=A0 A non-=
sign

=C2=A0 =C2=A0language tag with a text media stream is interpreted as an

=C2=A0 =C2=A0indication for written language in the text stream.=C2=A0 A no=
n-sign

=C2=A0 =C2=A0language tag with an audio media stream is interpreted as an
=C2=A0 =C2=A0indication for spoken language in the audio stream.



=C2=A0 =C2=A0This document does not define any other use for language tags =
in

=C2=A0 =C2=A0video media (such as how to indicate visible captions in the v=
ideo

=C2=A0 =C2=A0stream).



=C2=A0 =C2=A0In the IANA registry of language subtags per BCP 47 [RFC5646],=
 a

=C2=A0 =C2=A0language subtag with a Type field "extlang" combined=
 with a Prefix

=C2=A0 =C2=A0field value "sgn" indicates a sign language tag.=C2=
=A0 The absense of

=C2=A0 =C2=A0such "sgn" prefix indicates a non-sign language tag.=




=C2=A0 =C2=A0This document does not define the use of sign language tags in=
 text

=C2=A0 =C2=A0or audio media.



=C2=A0 =C2=A0This document does not define the use of language tags in medi=
a

=C2=A0 =C2=A0other than interactive streams of audio, video, and text (such=
 as

=C2=A0 =C2=A0"message" or "application").=C2=A0 Such us=
e could be supported by future

=C2=A0 =C2=A0work or by application agreement.




At 11:50 PM +0100 11/21/17, Gunnar Hellstr=C3=B6m wrote:





=C2=A0Den 2017-11-21 kl. 23:08, skrev Randall Gellens:





=C2=A0Based on the text and comments from Gunnar, brian, Paul, and Bernard,=
 here is what I propose to replace section 5.4 with:



=C2=A05.4. Usage Notes



=C2=A0A sign language tag with a video stream is interpreted as an

=C2=A0indication for sign language in the video stream. A non-sign

=C2=A0language tag with text media is interpreted as an indication for

=C2=A0written language. A non-sign language tag with audio media is

=C2=A0interpreted as an indication for spoken language.



=C2=A0In the IANA registry of language subtags per BCP 47 [RFC5646], a

=C2=A0language subtag with a Type field "extlang" combined with a=
 Prefix

=C2=A0field value "sgn" indicates a sign language tag. The absens=
e of

=C2=A0such "sgn" prefix indicates a non-sign language tag. This d=
ocument

=C2=A0does not define any other use for language tags in video media

=C2=A0(such as how to indicate visible captions).



=C2=A0This document does not define the use of sign language tags in text
=C2=A0or audio media.



=C2=A0This document does not define the use of language tags in media

=C2=A0other than interactive streams of audio, video, and text (such as

=C2=A0"message" or "application").





=C2=A0<GH> Good, I hope that "non-sign language" can be an =
accepted term.

=C2=A0I provide a slightly modified 5.4 proposal, with a bit more consisten=
t language in the first paragraph, and the mentioning of further work or ap=
plication agreement reinserted. I think that is better than just saying tha=
t it is not defined. I also added the spoken language in video is a view of=
 a speaker according to recent discussion in another mail.

=C2=A0I really hope to find that we are converging now.



=C2=A0------------------------------new text -------------------------=
------------------

=C2=A05.4 Media, Language and Modality indications



=C2=A0A sign language tag with video media is interpreted as an

=C2=A0indication for sign language in the video stream. A non-sign

=C2=A0language tag with text media is interpreted as an indication for

=C2=A0written language. A non-sign language tag with audio media is

=C2=A0interpreted as an indication for spoken language. A non-sign

=C2=A0language tag with video media is interpreted as a view of a

=C2=A0speaking person. This document does not define any other

=C2=A0use for language tags in video media (such as how to indicate

=C2=A0visible captions in the video stream).



=C2=A0In the IANA registry of language subtags per BCP 47 [RFC5646], a

=C2=A0language subtag with a Type field "extlang" combined with a=
 Prefix

=C2=A0field value "sgn" indicates a sign language tag. The absens=
e of

=C2=A0such "sgn" prefix indicates a non-sign language tag.



=C2=A0This document does not define the use of sign language tags in text
=C2=A0or audio media. This document does not define the use of language tag=
s in media

=C2=A0other than interactive streams of audio, video, and text (such as

=C2=A0"message" or "application"). Such use may be supp=
orted by further work

=C2=A0or application specific agreements.





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

=C2=A0Gunnar

=C2=A0--

=C2=A0-----------------------------------------

=C2=A0Gunnar Hellstr=C3=B6m

=C2=A0Omnitor

=C2=A0<mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se
=C2=A0+46 708 204 288



=C2=A0_______________________________________________

=C2=A0SLIM mailing list

=C2=A0SLIM@ietf.org<=
br>
=C2=A0https://www.ietf.org/mailman/listinfo/slim<=
br>






-- 

Randall Gellens

Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak=
 for myself only

-------------- Randomly selected tag: ---------------

Never knock the way the other cat swings.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0--Neal Cassady





--94eb2c0949d027fa88055e88ed8e--


From nobody Tue Nov 21 19:05:06 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 C1A8B129C0B; Tue, 21 Nov 2017 19:05:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: slim@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151131990476.13215.8587456250790976923@ietfa.amsl.com>
Date: Tue, 21 Nov 2017 19:05:04 -0800
Archived-At: 
Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-18.txt
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: Wed, 22 Nov 2017 03:05:05 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media WG of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-18.txt
	Pages           : 16
	Date            : 2017-11-21

Abstract:
   Users have various human (natural) language needs, abilities, and
   preferences regarding spoken, written, and signed languages.  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.  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 media
   attributes.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-18
https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-18

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


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

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


From nobody Tue Nov 21 21:48:41 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 D6C3112EABD for ; Tue, 21 Nov 2017 21:48:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.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 5XUDoeB1r4-X for ; Tue, 21 Nov 2017 21:48:37 -0800 (PST)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0114.outbound.protection.outlook.com [104.47.92.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEAD12EAB8 for ; Tue, 21 Nov 2017 21:48:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k/RBoHG9Yuf3g9yw24y7+6hBr4RdfTh2WyDFIRC70hY=; b=E8HmnrA+szFyMIfVdG7Oqo96qKjoumfUOZziyAiFj7BCMW2LM/mYMMbIpEd4F7VfbJjJN6MU22rgj5Bnwv/EhPfUYZpgoXnzHrLQQkmZ5yLSz6MCPrTiGwam9tWVsG9lJpkPdnsu1Qp0VBD39dgUFj1FglSX3hmmPuRl9TxxuQc=
Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0254.jpnprd01.prod.outlook.com (10.161.135.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 22 Nov 2017 05:48:33 +0000
To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> 
From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: 
Date: Wed, 22 Nov 2017 14:48:27 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [133.2.210.64]
X-ClientProxiedBy: OS2PR01CA0123.jpnprd01.prod.outlook.com (10.174.152.17) To TY1PR01MB0254.jpnprd01.prod.outlook.com (10.161.135.18)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ad356314-b3c0-4c07-ffdf-08d5316cab03
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600022)(4604075)(2017052603258); SRVR:TY1PR01MB0254; 
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0254; 3:I5JCE8olvTQwiVM7JVnWQXvvhpKajK5VzayEagXl+7NS823MNndQSavYwIEjMoiDG6QKk47sU/UabNQOPgyjs6yS5DBQxwynRCzj4YDCsWS13NX3iO7ThMehXffQsSLQBUsG/+Y7xhOO4Jj7iYMsEyFmAKnS+Okv6D850CFVVdDdbYh+EFdbCfcy0mz46N5AJuaQdZP7zRrq6PV//QvMNRgA6WxKhXeL6hzooSblsKLyi95J27arutNcISrk0rnk; 25:icpmYkJ7/bFmBRwJZ/HuOAAhEx/rTOWRZYH3QC2+pRrt2VweS6BJJtLBg7JAI7GlPpdBv/fb8NNsgY/kccDPGRhH7nKKWpYqjWWoXTcmZ0Sn5EtuGqSTdvFJWpCsrRqnJEApXIFWkiqI1egPS3qp0kXxsJM4vOwhOe0ROH46j7Lk7TPiMX5ndKbQhKP8a+XmiRRH/+MEW9zpR+HFDuslu0T+LRUDEhPSpaT4fdQn2LpYepexgn/A4FTXs7b6GXoVxjsvPvh/qd8ygYebfZJphBbRRBaBHaRP8p5X5eNIbAZNnYkM5iAg7z8vZ0o1G7aQnQIQLFWKmsB28v76bT2caaHeecPmkH8EZ1PdpFbeTY4=; 31:Urz9nQGS6d119noaBmLpP3SIYhQ9Md5XX/PY9K+aElsgtxQQDluVk7Llsig9Q18DpDi+h7/BrZ/dE3I5kIQmp+K7+G1VklNwBHkSuAdTd+EwKk1m7zQqjho6hyw3mbIASpdJZHUkmgKt1Nb2dlbWzwP+LQU9QCeAPhwKH3tZaDIH0DXl8McuQxylxNJ0V+QxW9fTJDPJxPHP1X6YTl4YW8pDid6gApLAAH0CQoVa1mY=
X-MS-TrafficTypeDiagnostic: TY1PR01MB0254:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281529075)(201703061421075)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:TY1PR01MB0254; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:TY1PR01MB0254; 
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0254; 4:c9ZBWUOd5V0vr2ii2sBw86jWEXQnlILHBL9/UEUotYKvtUB25YvleMdYymUHfGuWcFsM36KZiRjVyqvr10TrplBf/US+v1q+/SVk5uO1FvOWm59WRlB2DvsuVONYeId1h33WrDX8GsMK2r5UkYgeYJ9+/i0OOsbxtmAIMM59267//khe/T2Bv0Bm7OPGeKw13ShjiRiQMdNJz88RJpz3e/wb7hieEP9c9VqBRYxytK48hakoWCSdC0ZtIAeyfLmPlu0YTvl7t3zAFYPH9Xx6EQ==
X-Forefront-PRVS: 0499DAF22A
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(376002)(346002)(199003)(24454002)(189002)(6666003)(97736004)(229853002)(2950100002)(6306002)(6246003)(53546010)(47776003)(65806001)(66066001)(65956001)(8676002)(74482002)(110136005)(58126008)(81156014)(81166006)(6116002)(76176999)(25786009)(8936002)(42882006)(31696002)(39060400002)(86362001)(54356999)(50986999)(4326008)(3846002)(53936002)(561944003)(64126003)(189998001)(7736002)(93886005)(68736007)(508600001)(83506002)(67846002)(50466002)(101416001)(106356001)(105586002)(786003)(33646002)(230783001)(16576012)(23676004)(52146003)(5660300001)(90366009)(2486003)(16526018)(6486002)(65826007)(2870700001)(2906002)(36916002)(31686004)(305945005)(966005)(49976008)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0254; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMjU0OzIzOjFxSVFHRTdVV2lwZ1ZYUGxISkFFQ3dKeFBq?= =?utf-8?B?OG1yYVNHczdobmNIczBJT1VkWEF6bDJTOFRaemFXRXVuNURFc0pkdm1CUVRJ?= =?utf-8?B?OXFoajltWVkwUlk5WmZheDdwbkp5N085d09JU2hTTVRwSEhEcFpGTnpZZkVK?= =?utf-8?B?SFFxVzRDOHZEOC91Y3pXeTdOMzVLMENyaEo4cTJETWg3K0hzdHl1cGFpN1Jt?= =?utf-8?B?WnhBTWl2dk1WZHNwOHBVcm5DM1MzV2NQMGIvWlZ2Q3lsUTdGZ2JYbkdwMjdL?= =?utf-8?B?YjNDNlZnWE5iSjhXeTlpZGx5b2NuUHk4NElOUG01OFJONFlCSWhka0pnS2p3?= =?utf-8?B?RXUzdFFuRFR4SWNTYzZEMS9zVStJWWRjbFZYSE42UERXR3FsUVFUR3ovVHgz?= =?utf-8?B?Mm5pK1hZZFZyOFR6cGFzNTR3alptQ0VKWnFFWGsxWWs2M05naUxmaTJQN3BT?= =?utf-8?B?K1pEZnRoWkg5WWgrMlZ2NFo5cXM2dGRGcVJld3VJS1FSUFBoRTljeWVmNDNX?= =?utf-8?B?U08vaWlzZktMTTUzMWxNYjVMSlpXV2RLUm5nOElTNE80eE44ZXY0T0NMMEl5?= =?utf-8?B?Z0RvL3AxN1R3dHd4aHdnWkhKaHpFaE9ZZXQzckVDT1NaMk92clVPNlRxZ25Q?= =?utf-8?B?bHREODdjam1iRWp6enFoMTR3R2ZjTk1PNHNCTDE0bHRlSWZXMDFxVWtJZDRQ?= =?utf-8?B?YUMvUTZPQWtacHFRWStDWXIwT0hteXRzeEVnWGhJMzNPOHlXUXF3T0pPWWtH?= =?utf-8?B?S01BR0VkcHYyZHp1QVJKR01ycVR3ZTRiOWRockJtSnpLYzh6MW9FTnF5Vmds?= =?utf-8?B?VGZ0Sk01Z3hka25wS3FoVWdjcTEzaStmMlA0L3gzSTF4V1Q2d0oxaWtwaDJj?= =?utf-8?B?ZWwvWUtJbGxVcDg5WDUrSnlyL3ZlektXNFdQNnl5dVFVQ2tsQWRHanpNWGh6?= =?utf-8?B?SzRoZDJOMEtlRzhlZ2ZadGdlNnZVODVsZ1NXd2R2T1h3QlY0WGpzYzJSdllB?= =?utf-8?B?bENYQXBzcW9vU25ZOGxzTlRzZHgzREpMemdGc29zSUZVTHdiN1VsZHVtU1NZ?= =?utf-8?B?WnBQN2dRT1pCWHUyckEvYmNscW9UMklPbC9mOHZ4SkNaNTZXT3BJWmQ1c2Rt?= =?utf-8?B?bWNNd3ByMFRXc1Q0UU55UjAzUEt6dVptRGtVampSOTJoVVkzNDFaTWJFRnhn?= =?utf-8?B?NXJmdHU1SjlLVmxuc2ZwaTB3WXVBOXM0bHJlOXlDQnMwYmZxelNlcnFxOUFK?= =?utf-8?B?U3BHeHhoYmppakQvVXhFbGVZMm1lZXVNaDdRc0FSUHBia1ZpWDNyeWQrcFh0?= =?utf-8?B?VlNWNXBLclRFRDBSTDN4REl0ci96Tk5iRElRRTVRNkdXc1NnRjZKM1BHTmN2?= =?utf-8?B?WkR3OXlqRmZWRTJiM1lsQVlza0l3d0dDK2t6TjFlRjhsRWxLcHFaUldtZkhp?= =?utf-8?B?NDJoRjBtbSs3MDNHVytISUdZbXR6UlNaU3locE9Ybm02VC9WOUEvZVAxTFFr?= =?utf-8?B?aXoxMjQzYTVqRVVHYVhnZ3Z0TmtxSkw4UUt2UEhidCtzREloZm12K2VmcFR2?= =?utf-8?B?ZTM5aU9pSzN3a1ZBV1gxT0t0c3llTmVHUVF4bW9SemM5TVBxaC9HVzJxdTBB?= =?utf-8?B?QkJDOXRsM3BZL0lzREJjcUxPSXFiZURrOS9mNGFDaC9vdkVheDVJZTFlRFhz?= =?utf-8?B?TVZadVNUaW95enVjZGtyMllwSytMSDJVcFB6UEFEdGJQS2NmM2tnLzJEa01s?= =?utf-8?B?M2J4ZGJCS0IxWnh3bjduM3EwSm1iakowRjV2VTlLU3lTYUplL1NqaHN2Mmh4?= =?utf-8?B?TkZ6OFI4V0lVWEZHY0lnaG5YcFVjSDdGUDMyKzJxS2tqTFYrbS9RNGVtZjhp?= =?utf-8?B?RW9MRU5jeWR3NHdnS1UwMXBVQ2pGNDl1bDlSV0doVzBMdzhiVmhyM3pYRXIx?= =?utf-8?B?ZnF3VjBxMU5UcXlPRk96ZHUvM1pPMmxpTnhsWGxZVjltZ1FQbGt6UzhXOGdi?= =?utf-8?B?QnBWWUE2Rnh5SCt0akZQbnd0cEVrTHhtMlpkQ1E0OXIvM2ZBaFJ5dHdTYzRV?= =?utf-8?B?UUF0aG5YQXNQaksvVlpxRkhtRVlrYkdTd0QrRm1nWnZVbzk4dldQNDlCOWpi?= =?utf-8?Q?2TZY2OTe8OZVEEvPohznhAHaPdPfZVZNmYjYFsXsAsDh?=
X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0254; 6:hmAPuBvlmaqsw00qcQcxW0s9D5nJpqD1aVUrops0aXwp7UK+cELWXMWgodz87cA/LNXSzOT0/2A4F//qCiG3xVND2X77PQ8aXaMpL+vBfaeBCJY9K0GRlrMuJoYsYKPwxifyp93f0jzC23qoy+HSR5hI1J8sMHzphgzwfbtvRSZ4kpilU/4wRuqltQMmgDiOL8UQgPOz3bk7QVFZxBjwGFtmqVGRW4lCwZ3peR7A2k9T4pxJ0yS58BHVlpgfAAclOj2k7PpVgzY6TluJOczE8FuMwGb7GXkWEz04ss0xi2NDFttiPoDLJs0ySButO2jcm64F5MQH+aysXvFGIMtlKfgUxnPd6AFyZrshkcD7NSk=; 5:edEmWUrt99Wme8vahEqO4XDfGEqABh94QBaR/z1qJpieLeUeOlHk10oOqA/6rsLLDSH3ijPUm03g1CgsrGmPCK4qTBnRzVauCw+P+i5gvbUw6InC3X9UcHi01KJj0vYC/HNg1YXNr39r7yoPiFQbZ3Uq6pMCGRSJfDhJK1Z3N4g=; 24:QXDxA6sim3zoeUZ93Wf3c1V0L0wgg3L71N+52YyrjFZajSFM7EmZHsdVzH5E8ZsNFgOEgA1YTZyD06IoJHRpnEHtP2pbUKK5O2JDCZaeUzo=; 7:j78S4lcg5VuAc/RwR4ZI7/myPPmz5WRbSaYycs5bsGIOMw8PNgEJhXo4d2oai5sfoJxkNYg433CbwIg52tEkrBBuYSqpSR7g1FbrEnoJsNil2my4/TPOTbk2zx5jDTkUk+F/RIXrzzSomNWY/63CON7CTtu7/0wWb+BQqgN/4J+UGtg46ynv/4j9EEtPK7cdHm+kqwziRyoi33N3QqTtN7Zj8fekeG0pm9VrkGY9l186jcpxJoUGkZr4t1HX+vYf
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2017 05:48:33.1781 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ad356314-b3c0-4c07-ffdf-08d5316cab03
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0254
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 22 Nov 2017 05:48:40 -0000

On 2017/11/21 06:14, Gunnar Hellström wrote:
> A new proposal for new text taking in latest discussion of Bernard, Paul 
> and Brian:

> -----New text------------
> 5.4 Media, Language and Modality indications

> A sign language can be identified by the existence in the IANA registry 
> of language subtags according to BCP 47 [RFC5646] of the language subtag 
> with the Type field "extlang" combined with the Prefix field value "sgn".
> A specific spoken or written language can be identified by not having 
> any such "sgn" Prefix.

https://tools.ietf.org/html/rfc5646#section-3.4, point 12.C.3, currently 
says:

             3.  Sign languages SHOULD have an 'extlang' record with a
                 'Prefix' of 'sgn'.

As everybody here on this list knows, a SHOULD is not a guarantee, 
because there might be exceptions. The fact that there currently are no 
exceptions doesn't guarantee that there will be no exceptions in the future.

Regards,   Martin.


From nobody Tue Nov 21 22:29:27 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 BC3B112EB9A for ; Tue, 21 Nov 2017 22:29:25 -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 XBP51Zd3lt1B for ; Tue, 21 Nov 2017 22:29:23 -0800 (PST)
Received: from bin-vsp-out-01.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 8BF4512EB9C for ; Tue, 21 Nov 2017 22:29:23 -0800 (PST)
X-Halon-ID: 6e8b582d-cf4e-11e7-aaf4-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 6e8b582d-cf4e-11e7-aaf4-005056917a89; Wed, 22 Nov 2017 07:29:04 +0100 (CET)
To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens 
References:     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <89b3d094-b3b7-d396-f76d-1db415a98816@omnitor.se>
Date: Wed, 22 Nov 2017 07:29:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
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, 22 Nov 2017 06:29:26 -0000

Den 2017-11-22 kl. 06:48, skrev Martin J. Dürst:
> On 2017/11/21 06:14, Gunnar Hellström wrote:
>> A new proposal for new text taking in latest discussion of Bernard, 
>> Paul and Brian:
>
>> -----New text------------
>> 5.4 Media, Language and Modality indications
>
>> A sign language can be identified by the existence in the IANA 
>> registry of language subtags according to BCP 47 [RFC5646] of the 
>> language subtag with the Type field "extlang" combined with the 
>> Prefix field value "sgn".
>> A specific spoken or written language can be identified by not having 
>> any such "sgn" Prefix.
>
> https://tools.ietf.org/html/rfc5646#section-3.4, point 12.C.3, 
> currently says:
>
>             3.  Sign languages SHOULD have an 'extlang' record with a
>                 'Prefix' of 'sgn'.
>
> As everybody here on this list knows, a SHOULD is not a guarantee, 
> because there might be exceptions. The fact that there currently are 
> no exceptions doesn't guarantee that there will be no exceptions in 
> the future.
Right, but a new registration of a sign language in the future 
without registering the 'sgn' Prefix for it will risk to cause interop 
problems for that language, so that should not continuously be done. And 
if it is done, it should be corrected. And while it is in the process of 
being amended in the language registry, applications supporting that 
language could regard it to be a sign language anyway by application 
agreement.
So, I think we can live with it.

Gunnar
>
> Regards,   Martin.
>
> _______________________________________________
> 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 Nov 21 22:54:00 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 5837812EB00 for ; Tue, 21 Nov 2017 22:53:58 -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 tm2xWt41SxGy for ; Tue, 21 Nov 2017 22:53:55 -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 08C81129A84 for ; Tue, 21 Nov 2017 22:53:54 -0800 (PST)
X-Halon-ID: df97cd65-cf51-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id df97cd65-cf51-11e7-96ae-005056917f90; Wed, 22 Nov 2017 07:53:43 +0100 (CET)
To: Bernard Aboba , Randall Gellens 
Cc: Brian Rosen , Paul Kyzivat , slim@ietf.org
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>  
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 22 Nov 2017 07:53:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A248CD5080EFDC4D9F6427EE"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 06:53:58 -0000

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

Randall,

1. You dropped one sentence from the first paragraph in my latest proposal:

"A non-sign language tag with video media is interpreted as a view of a
  speaking person."

It was a result of the previous discussion and reasoning, and I think it 
should be reinserted.

2. You also changed the title proposal from " 5.4 Media, Language and 
Modality indications" to "5.4 Usage Notes"

I think it is better to have a title that tells about the topic of the 
paragraph. I suggest to use the title I proposed, but I can accept yours 
if you have a good reason for the change.

Thanks,

Gunnar


Den 2017-11-22 kl. 03:17, skrev Bernard Aboba:
> Looks good to me.
>
> On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens 
> > wrote:
>
>     I agree. I made a few minor editorial changes (e.g., moving some
>     text to a new paragraph):
>
>     5.4.  Usage Notes
>
>        A sign language tag with a video media stream is interpreted as an
>        indication for sign language in the video stream.  A non-sign
>        language tag with a text media stream is interpreted as an
>        indication for written language in the text stream.  A non-sign
>        language tag with an audio media stream is interpreted as an
>        indication for spoken language in the audio stream.
>
>        This document does not define any other use for language tags in
>        video media (such as how to indicate visible captions in the video
>        stream).
>
>        In the IANA registry of language subtags per BCP 47 [RFC5646], a
>        language subtag with a Type field "extlang" combined with a Prefix
>        field value "sgn" indicates a sign language tag.  The absense of
>        such "sgn" prefix indicates a non-sign language tag.
>
>        This document does not define the use of sign language tags in text
>        or audio media.
>
>        This document does not define the use of language tags in media
>        other than interactive streams of audio, video, and text (such as
>        "message" or "application").  Such use could be supported by future
>        work or by application agreement.
>
>
>     At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:
>
>          Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
>
>              Based on the text and comments from Gunnar, brian, Paul,
>             and Bernard, here is what I propose to replace section 5.4
>             with:
>
>              5.4. Usage Notes
>
>              A sign language tag with a video stream is interpreted as an
>              indication for sign language in the video stream. A non-sign
>              language tag with text media is interpreted as an
>             indication for
>              written language. A non-sign language tag with audio media is
>              interpreted as an indication for spoken language.
>
>              In the IANA registry of language subtags per BCP 47
>             [RFC5646], a
>              language subtag with a Type field "extlang" combined with
>             a Prefix
>              field value "sgn" indicates a sign language tag. The
>             absense of
>              such "sgn" prefix indicates a non-sign language tag. This
>             document
>              does not define any other use for language tags in video
>             media
>              (such as how to indicate visible captions).
>
>              This document does not define the use of sign language
>             tags in text
>              or audio media.
>
>              This document does not define the use of language tags in
>             media
>              other than interactive streams of audio, video, and text
>             (such as
>              "message" or "application").
>
>           Good, I hope that "non-sign language" can be an accepted
>         term.
>          I provide a slightly modified 5.4 proposal, with a bit more
>         consistent language in the first paragraph, and the mentioning
>         of further work or application agreement reinserted. I think
>         that is better than just saying that it is not defined. I also
>         added the spoken language in video is a view of a speaker
>         according to recent discussion in another mail.
>          I really hope to find that we are converging now.
>
>          ------------------------------new text
>         -------------------------------------------
>          5.4 Media, Language and Modality indications
>
>          A sign language tag with video media is interpreted as an
>          indication for sign language in the video stream. A non-sign
>          language tag with text media is interpreted as an indication for
>          written language. A non-sign language tag with audio media is
>          interpreted as an indication for spoken language. A non-sign
>          language tag with video media is interpreted as a view of a
>          speaking person. This document does not define any other
>          use for language tags in video media (such as how to indicate
>          visible captions in the video stream).
>
>          In the IANA registry of language subtags per BCP 47 [RFC5646], a
>          language subtag with a Type field "extlang" combined with a
>         Prefix
>          field value "sgn" indicates a sign language tag. The absense of
>          such "sgn" prefix indicates a non-sign language tag.
>
>          This document does not define the use of sign language tags
>         in text
>          or audio media. This document does not define the use of
>         language tags in media
>          other than interactive streams of audio, video, and text (such as
>          "message" or "application"). Such use may be supported by
>         further work
>          or application specific agreements.
>
>
>         ---------------------------------------------------------------------------------------------
>          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
>         
>
>
>
>     -- 
>     Randall Gellens
>     Opinions are personal;    facts are suspect;    I speak for myself
>     only
>     -------------- Randomly selected tag: ---------------
>     Never knock the way the other cat swings.
>                              --Neal Cassady
>
>

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


--------------A248CD5080EFDC4D9F6427EE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Randall, 

    

    
1. You dropped one sentence from the first paragraph in my latest
      proposal:

    
"A non-sign language tag with video media is interpreted as a
      view of a

       speaking person."

    
It was a result of the previous discussion and reasoning, and I
      think it should be reinserted. 

    

    
2. You also changed the title proposal from " 5.4 Media, Language
      and Modality indications" to "5.4 Usage Notes"

    
I think it is better to have a title that tells about the topic
      of the paragraph. I suggest to use the title I proposed, but I can
      accept yours if you have a good reason for the change.

    
Thanks,

    
Gunnar

    

    

    
Den 2017-11-22 kl. 03:17, skrev Bernard
      Aboba:

    

    

      
Looks good to me. 

      


        
On Tue, Nov 21, 2017 at 3:17 PM,
          Randall Gellens <rg+ietf@randy.pensive.org>
          wrote:

          
I agree. 
            I made a few minor editorial changes (e.g., moving some text
            to a new paragraph):

            

            5.4.  Usage Notes

            

               A sign language tag with a video media stream is
            interpreted as an

                 indication for sign language in the video stream.  A
              non-sign

            
               language tag with a text media stream is interpreted as
            an

               indication for written language in the text stream.  A
            non-sign

               language tag with an audio media stream is interpreted as
            an

               indication for spoken language in the audio stream.

              

                 This document does not define any other use for
              language tags in

                 video media (such as how to indicate visible captions
              in the video

                 stream).

              

                 In the IANA registry of language subtags per BCP 47
              [RFC5646], a

                 language subtag with a Type field "extlang" combined
              with a Prefix

                 field value "sgn" indicates a sign language tag.  The
              absense of

                 such "sgn" prefix indicates a non-sign language tag.

              

                 This document does not define the use of sign language
              tags in text

                 or audio media.

              

                 This document does not define the use of language tags
              in media

                 other than interactive streams of audio, video, and
              text (such as

            
               "message" or "application").  Such use could be supported
            by future

               work or by application agreement.
            

              


                

                At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:

                

              

            

            

              

                

                   Den 2017-11-21 kl. 23:08, skrev Randall Gellens:

                  

                  

                     Based on the text and comments from Gunnar, brian,
                    Paul, and Bernard, here is what I propose to replace
                    section 5.4 with:

                    

                     5.4. Usage Notes

                    

                     A sign language tag with a video stream is
                    interpreted as an

                     indication for sign language in the video stream. A
                    non-sign

                     language tag with text media is interpreted as an
                    indication for

                     written language. A non-sign language tag with
                    audio media is

                     interpreted as an indication for spoken language.

                    

                     In the IANA registry of language subtags per BCP 47
                    [RFC5646], a

                     language subtag with a Type field "extlang"
                    combined with a Prefix

                     field value "sgn" indicates a sign language tag.
                    The absense of

                     such "sgn" prefix indicates a non-sign language
                    tag. This document

                     does not define any other use for language tags in
                    video media

                     (such as how to indicate visible captions).

                    

                     This document does not define the use of sign
                    language tags in text

                     or audio media.

                    

                     This document does not define the use of language
                    tags in media

                     other than interactive streams of audio, video, and
                    text (such as

                     "message" or "application").

                    

                  

                   <GH> Good, I hope that "non-sign language" can
                  be an accepted term.

                   I provide a slightly modified 5.4 proposal, with a
                  bit more consistent language in the first paragraph,
                  and the mentioning of further work or application
                  agreement reinserted. I think that is better than just
                  saying that it is not defined. I also added the spoken
                  language in video is a view of a speaker according to
                  recent discussion in another mail.

                   I really hope to find that we are converging now.

                  

                   ------------------------------new text
                  -------------------------------------------

                   5.4 Media, Language and Modality indications

                  

                   A sign language tag with video media is interpreted
                  as an

                   indication for sign language in the video stream. A
                  non-sign

                   language tag with text media is interpreted as an
                  indication for

                   written language. A non-sign language tag with audio
                  media is

                   interpreted as an indication for spoken language. A
                  non-sign

                   language tag with video media is interpreted as a
                  view of a

                   speaking person. This document does not define any
                  other

                   use for language tags in video media (such as how to
                  indicate

                   visible captions in the video stream).

                  

                   In the IANA registry of language subtags per BCP 47
                  [RFC5646], a

                   language subtag with a Type field "extlang" combined
                  with a Prefix

                   field value "sgn" indicates a sign language tag. The
                  absense of

                   such "sgn" prefix indicates a non-sign language tag.

                  

                   This document does not define the use of sign
                  language tags in text

                   or audio media. This document does not define the use
                  of language tags in media

                   other than interactive streams of audio, video, and
                  text (such as

                   "message" or "application"). Such use may be
                  supported by further work

                   or application specific agreements.

                  

                  

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

                   Gunnar

                   --

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

                   Gunnar Hellström

                   Omnitor

                

              

               <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se

               +46 708 204 288

              

               _______________________________________________

               SLIM mailing list

               SLIM@ietf.org

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

            

            
              

              

              -- 

              Randall Gellens

              Opinions are personal;    facts are suspect;    I speak
              for myself only

              -------------- Randomly selected tag: ---------------

            
            Never knock the way the other cat swings.

                                     --Neal Cassady

          

        

        

      

    

    

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

  


--------------A248CD5080EFDC4D9F6427EE--


From nobody Tue Nov 21 23:17:45 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 E27011287A0 for ; Tue, 21 Nov 2017 23:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 5V8cW9MAnRdA for ; Tue, 21 Nov 2017 23:17:40 -0800 (PST)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 8200F126B71 for ; Tue, 21 Nov 2017 23:17:40 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id l189so426276vkl.6 for ; Tue, 21 Nov 2017 23:17:40 -0800 (PST)
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=Jmt0GakVpFIO0ZgMVrcoaSm4xlCH56LT0DkYFpoXh3s=; b=lpCFKqPxQeGNEghlZQL99evgpAzFYK070dTxGlwnkGxpOHOnxZuJYlSbot2M7GEx8w J6OdWC0z4c89zBsZKj7AUJA8/qCqPufxlI7yZwyjP2YVkA5pDm9GhqmuMt5Yu0UK7PhA Ku3df0ljQcSo99d2OH8tPZLGpdyzX+1naO0Zz6MF4EsNniWUGK6235o7zZmarAiTUh0t Cd42psTQxwv1vAFOoI6Q8vK3gjzZkY8IwjHy3u2ZKVQtzTM9VCAUxyc4ppvsLGNFGe0f OHGQgFrfdBgqcuuCbxUy8H4Ag/e+bAJavZ97+Cgs6m+OD0QmE0AiotuPPruc3hztzlzm Uy/g==
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=Jmt0GakVpFIO0ZgMVrcoaSm4xlCH56LT0DkYFpoXh3s=; b=Oljn0AB4zmpa48ZoAguqHtjBBtCJ4jceIxSrt3OVflrLRmEqBxVUfLi45bUF+LMijf dShEagx26arTA0gqxgXwroOOCWT2786VPzrCTtviXFBBgH3hNbtbbYGthgkiAWE6Iqzd 1CCZTFRTxLL8rvCCyg7Btz8fgpBW5KdUIh+eyPVDBrOBo3y2i0eLYgaljraO6a3vRHXr +41n+mxbJgg6Ow+6mIYhTGr+kFwSAduef5P5mzXK1YQ92P23B1ShaioV1WFlfy+eaELq OwJcoROyyWkPXCB59fsOYj56gw8s2IvecO2yEL9+izPuYR9GD+UAUSYEHAoZpjpJG7d1 O51g==
X-Gm-Message-State: AJaThX60mHMhiQwH09ADhGJCAA2suVlNtpIt3tRh/L9U2/PvO19ZDSxM 6O9spwim5n5c/DgDxrBCBoQR3bm2iRFQ4XgziZLCyXkY
X-Google-Smtp-Source: AGs4zMYSloOmFvmvSwTaNWqhe+FnAOUaG6ebb1EoRwCd/xCfWGmWfGgpInYt80mkdcPgOZnJ71JQPv0FthTfHYuRmUE=
X-Received: by 10.31.163.10 with SMTP id m10mr4253511vke.85.1511335059424; Tue, 21 Nov 2017 23:17:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 23:17:18 -0800 (PST)
In-Reply-To: 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>   
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 23:17:18 -0800
Message-ID: 
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= 
Cc: Randall Gellens , Brian Rosen ,  Paul Kyzivat , slim@ietf.org
Content-Type: multipart/alternative; boundary="001a1142e8c65a8ac8055e8d1d51"
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 07:17:44 -0000

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

Gunnar said:

"A non-sign language tag with video media is interpreted as a view of
a speaking
person"

[BA] I believe that Paul pointed out that such a need can be met by asking
for audio with the non-sign language tag and RFC 5888 lip sync grouping,
with no language tag for the video.

On Tue, Nov 21, 2017 at 10:53 PM, Gunnar Hellstr=C3=B6m <
gunnar.hellstrom@omnitor.se> wrote:

> Randall,
>
> 1. You dropped one sentence from the first paragraph in my latest proposa=
l:
>
> "A non-sign language tag with video media is interpreted as a view of a
>  speaking person."
>
> It was a result of the previous discussion and reasoning, and I think it
> should be reinserted.
>
> 2. You also changed the title proposal from " 5.4 Media, Language and
> Modality indications" to "5.4 Usage Notes"
>
> I think it is better to have a title that tells about the topic of the
> paragraph. I suggest to use the title I proposed, but I can accept yours =
if
> you have a good reason for the change.
>
> Thanks,
>
> Gunnar
>
> Den 2017-11-22 kl. 03:17, skrev Bernard Aboba:
>
> Looks good to me.
>
> On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens <
> rg+ietf@randy.pensive.org> wrote:
>
>> I agree.  I made a few minor editorial changes (e.g., moving some text t=
o
>> a new paragraph):
>>
>> 5.4.  Usage Notes
>>
>>    A sign language tag with a video media stream is interpreted as an
>>    indication for sign language in the video stream.  A non-sign
>>    language tag with a text media stream is interpreted as an
>>    indication for written language in the text stream.  A non-sign
>>    language tag with an audio media stream is interpreted as an
>>    indication for spoken language in the audio stream.
>>
>>    This document does not define any other use for language tags in
>>    video media (such as how to indicate visible captions in the video
>>    stream).
>>
>>    In the IANA registry of language subtags per BCP 47 [RFC5646], a
>>    language subtag with a Type field "extlang" combined with a Prefix
>>    field value "sgn" indicates a sign language tag.  The absense of
>>    such "sgn" prefix indicates a non-sign language tag.
>>
>>    This document does not define the use of sign language tags in text
>>    or audio media.
>>
>>    This document does not define the use of language tags in media
>>    other than interactive streams of audio, video, and text (such as
>>    "message" or "application").  Such use could be supported by future
>>    work or by application agreement.
>>
>>
>> At 11:50 PM +0100 11/21/17, Gunnar Hellstr=C3=B6m wrote:
>>
>>  Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
>>>
>>>  Based on the text and comments from Gunnar, brian, Paul, and Bernard,
>>>> here is what I propose to replace section 5.4 with:
>>>>
>>>>  5.4. Usage Notes
>>>>
>>>>  A sign language tag with a video stream is interpreted as an
>>>>  indication for sign language in the video stream. A non-sign
>>>>  language tag with text media is interpreted as an indication for
>>>>  written language. A non-sign language tag with audio media is
>>>>  interpreted as an indication for spoken language.
>>>>
>>>>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>>>>  language subtag with a Type field "extlang" combined with a Prefix
>>>>  field value "sgn" indicates a sign language tag. The absense of
>>>>  such "sgn" prefix indicates a non-sign language tag. This document
>>>>  does not define any other use for language tags in video media
>>>>  (such as how to indicate visible captions).
>>>>
>>>>  This document does not define the use of sign language tags in text
>>>>  or audio media.
>>>>
>>>>  This document does not define the use of language tags in media
>>>>  other than interactive streams of audio, video, and text (such as
>>>>  "message" or "application").
>>>>
>>>>   Good, I hope that "non-sign language" can be an accepted term.
>>>  I provide a slightly modified 5.4 proposal, with a bit more consistent
>>> language in the first paragraph, and the mentioning of further work or
>>> application agreement reinserted. I think that is better than just sayi=
ng
>>> that it is not defined. I also added the spoken language in video is a =
view
>>> of a speaker according to recent discussion in another mail.
>>>  I really hope to find that we are converging now.
>>>
>>>  ------------------------------new text ------------------------------
>>> -------------
>>>  5.4 Media, Language and Modality indications
>>>
>>>  A sign language tag with video media is interpreted as an
>>>  indication for sign language in the video stream. A non-sign
>>>  language tag with text media is interpreted as an indication for
>>>  written language. A non-sign language tag with audio media is
>>>  interpreted as an indication for spoken language. A non-sign
>>>  language tag with video media is interpreted as a view of a
>>>  speaking person. This document does not define any other
>>>  use for language tags in video media (such as how to indicate
>>>  visible captions in the video stream).
>>>
>>>  In the IANA registry of language subtags per BCP 47 [RFC5646], a
>>>  language subtag with a Type field "extlang" combined with a Prefix
>>>  field value "sgn" indicates a sign language tag. The absense of
>>>  such "sgn" prefix indicates a non-sign language tag.
>>>
>>>  This document does not define the use of sign language tags in text
>>>  or audio media. This document does not define the use of language tags
>>> in media
>>>  other than interactive streams of audio, video, and text (such as
>>>  "message" or "application"). Such use may be supported by further work
>>>  or application specific agreements.
>>>
>>>
>>> ------------------------------------------------------------
>>> ---------------------------------
>>>  Gunnar
>>>  --
>>>  -----------------------------------------
>>>  Gunnar Hellstr=C3=B6m
>>>  Omnitor
>>>  gunnar.hellstrom@omnitor.se
>>>  +46 708 204 288
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  SLIM@ietf.org
>>>  https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>
>> --
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for myself only
>> -------------- Randomly selected tag: ---------------
>> Never knock the way the other cat swings.
>>                          --Neal Cassady
>>
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>

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


Gunnar said:=C2=A0

"A non-sign language tag with video me=
dia is interpreted as a view of a=C2=A0speaking person"

[BA] I believe that Paul pointed out that such a need can be met by askin=
g for audio with the non-sign language tag and RFC 5888 lip sync grouping, =
with no language tag for the video.=C2=A0

On Tue, Nov 21, 2017 at 10:53 PM, Gunna=
r Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wro=
te:

 =20
   =20
 =20
  

    
Randall, 

    

    
1. You dropped one sentence from the first paragraph in my latest
      proposal:

    
"A non-sign language tag with video media is interpreted as a
      view of a

      =C2=A0speaking person."

    
It was a result of the previous discussion and reasoning, and=
 I
      think it should be reinserted. 

    

    
2. You also changed the title proposal from " 5.4 Media, Langua=
ge
      and Modality indications" to "5.4 Usage Notes"

    
I think it is better to have a title that tells about the topic
      of the paragraph. I suggest to use the title I proposed, but I can
      accept yours if you have a good reason for the change.

    
Thanks,

    
Gunnar

    

    

    
Den 2017-11-22 kl. =
03:17, skrev Bernard
      Aboba:

    

    

      
Looks good to me.=C2=A0

      


        
On Tue, Nov 21, 2017 at 3:17 PM,
          Randall Gellens <rg+ietf@randy.pensive.org>
          wrote:

          
I agree.=C2=A0
            I made a few minor editorial changes (e.g., moving some text
            to a new paragraph):

            

            5.4.=C2=A0 Usage Notes

            

            =C2=A0 =C2=A0A sign language tag with a video media stream is
            interpreted as an

              =C2=A0 =C2=A0indication for sign language in the video stream=
.=C2=A0 A
              non-sign

            
            =C2=A0 =C2=A0language tag with a text media stream is interpret=
ed as
            an

            =C2=A0 =C2=A0indication for written language in the text stream=
.=C2=A0 A
            non-sign

            =C2=A0 =C2=A0language tag with an audio media stream is interpr=
eted as
            an

            =C2=A0 =C2=A0indication for spoken language in the audio stream=
.

              

              =C2=A0 =C2=A0This document does not define any other use for
              language tags in

              =C2=A0 =C2=A0video media (such as how to indicate visible cap=
tions
              in the video

              =C2=A0 =C2=A0stream).

              

              =C2=A0 =C2=A0In the IANA registry of language subtags per BCP=
 47
              [RFC5646], a

              =C2=A0 =C2=A0language subtag with a Type field "extlang&=
quot; combined
              with a Prefix

              =C2=A0 =C2=A0field value "sgn" indicates a sign lan=
guage tag.=C2=A0 The
              absense of

              =C2=A0 =C2=A0such "sgn" prefix indicates a non-sign=
 language tag.

              

              =C2=A0 =C2=A0This document does not define the use of sign la=
nguage
              tags in text

              =C2=A0 =C2=A0or audio media.

              

              =C2=A0 =C2=A0This document does not define the use of languag=
e tags
              in media

              =C2=A0 =C2=A0other than interactive streams of audio, video, =
and
              text (such as

            
            =C2=A0 =C2=A0"message" or "application").=
=C2=A0 Such use could be supported
            by future

            =C2=A0 =C2=A0work or by application agreement.
            

              


                

                At 11:50 PM +0100 11/21/17, Gunnar Hellstr=C3=B6m wrote:
                

              

            

            

              

                

                  =C2=A0Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
                  

                  

                    =C2=A0Based on the text and comments from Gunnar, brian=
,
                    Paul, and Bernard, here is what I propose to replace
                    section 5.4 with:

                    

                    =C2=A05.4. Usage Notes

                    

                    =C2=A0A sign language tag with a video stream is
                    interpreted as an

                    =C2=A0indication for sign language in the video stream.=
 A
                    non-sign

                    =C2=A0language tag with text media is interpreted as an
                    indication for

                    =C2=A0written language. A non-sign language tag with
                    audio media is

                    =C2=A0interpreted as an indication for spoken language.=


                    

                    =C2=A0In the IANA registry of language subtags per BCP =
47
                    [RFC5646], a

                    =C2=A0language subtag with a Type field "extlang&q=
uot;
                    combined with a Prefix

                    =C2=A0field value "sgn" indicates a sign lang=
uage tag.
                    The absense of

                    =C2=A0such "sgn" prefix indicates a non-sign =
language
                    tag. This document

                    =C2=A0does not define any other use for language tags i=
n
                    video media

                    =C2=A0(such as how to indicate visible captions).

                    

                    =C2=A0This document does not define the use of sign
                    language tags in text

                    =C2=A0or audio media.

                    

                    =C2=A0This document does not define the use of language
                    tags in media

                    =C2=A0other than interactive streams of audio, video, a=
nd
                    text (such as

                    =C2=A0"message" or "application").<=
br>
                    

                  

                  =C2=A0<GH> Good, I hope that "non-sign languag=
e" can
                  be an accepted term.

                  =C2=A0I provide a slightly modified 5.4 proposal, with a
                  bit more consistent language in the first paragraph,
                  and the mentioning of further work or application
                  agreement reinserted. I think that is better than just
                  saying that it is not defined. I also added the spoken
                  language in video is a view of a speaker according to
                  recent discussion in another mail.

                  =C2=A0I really hope to find that we are converging now.
                  

                  =C2=A0------------------------------new text
                  -------------------------------------------

                  =C2=A05.4 Media, Language and Modality indications

                  

                  =C2=A0A sign language tag with video media is interpreted
                  as an

                  =C2=A0indication for sign language in the video stream. A
                  non-sign

                  =C2=A0language tag with text media is interpreted as an
                  indication for

                  =C2=A0written language. A non-sign language tag with audi=
o
                  media is

                  =C2=A0interpreted as an indication for spoken language. A
                  non-sign

                  =C2=A0language tag with video media is interpreted as a
                  view of a

                  =C2=A0speaking person. This document does not define any
                  other

                  =C2=A0use for language tags in video media (such as how t=
o
                  indicate

                  =C2=A0visible captions in the video stream).

                  

                  =C2=A0In the IANA registry of language subtags per BCP 47
                  [RFC5646], a

                  =C2=A0language subtag with a Type field "extlang&quo=
t; combined
                  with a Prefix

                  =C2=A0field value "sgn" indicates a sign langua=
ge tag. The
                  absense of

                  =C2=A0such "sgn" prefix indicates a non-sign la=
nguage tag.

                  

                  =C2=A0This document does not define the use of sign
                  language tags in text

                  =C2=A0or audio media. This document does not define the u=
se
                  of language tags in media

                  =C2=A0other than interactive streams of audio, video, and
                  text (such as

                  =C2=A0"message" or "application"). Su=
ch use may be
                  supported by further work

                  =C2=A0or application specific agreements.

                  

                  

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

                  =C2=A0Gunnar

                  =C2=A0--

                  =C2=A0-----------------------------------------

                  =C2=A0Gunnar Hellstr=C3=B6m

                  =C2=A0Omnitor

                

              

              =C2=A0<mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnito<=
wbr>r.se

              =C2=A0+46 708 204 288

              

              =C2=A0_______________________________________________
              =C2=A0SLIM mailing list

              =C2=A0SLIM=
@ietf.org

              =C2=A0https://www.ietf.org/mailman/list=
info/slim

            

            
              

              

              -- 

              Randall Gellens

              Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =
=C2=A0 I speak
              for myself only

              -------------- Randomly selected tag: ---------------

            
            Never knock the way the other cat swings.

            =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0--Neal Cassady

          

        

        

      

    

    

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

  






--001a1142e8c65a8ac8055e8d1d51--


From nobody Tue Nov 21 23:21: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 DC68712896F for ; Tue, 21 Nov 2017 23:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 zr8LJ5i3yVab for ; Tue, 21 Nov 2017 23:21:47 -0800 (PST)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 DDE8A1271DF for ; Tue, 21 Nov 2017 23:21:46 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id l201so8512690vkd.1 for ; Tue, 21 Nov 2017 23:21:46 -0800 (PST)
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;  bh=H2+2mZUI5HXLmUO0ihq9lF4GnP+OfURSrBeG+bS0Kwc=; b=Me325n1gszSQ7sc+HfRoXmJCQplUusgno4aipD1GTV6UaZ2Z8uAtDvPzWv6caKFlep gIeG8SKiPT2o1CICd/n8Fr05hzlOCNyEjy+0BlXWcYyhUStCoi4gPgRaBzUxLSUL1xid V0trueVqVJwWfIqSRmGTHGeALKapIvWFJsCvUnQ1/yDx7HTBUvs0l1peKaiun9PS6nt5 +oMEeInII/80FZuX5/pZOb4K8o6b3yGqPHRPaG7TKiUnJy5iongcYkdJwiPcuKmi/yNO 7zcxYdQiy49q6PEsIxZGCiIKTSmeet4bZ4DP9SgTw9V5qnApWlL6wG2heCua28fr0OPl yiPw==
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; bh=H2+2mZUI5HXLmUO0ihq9lF4GnP+OfURSrBeG+bS0Kwc=; b=rQWKUf/9j/cm2rnMZPirWOlH0xIKLTLRaOrOnUPcpRCBlXR/TEek/lhvOQn2tLsb4j Kt8XJz+9y1epukZ4gUm2wTfmZHHH/r0fssm0ln1FclrVHPO9k3D78DxLUsqWdLUDMOEO VuD3+GKSvhblxJJdJAvqy6DXdS2Iv2zRTnKRQR4+TtB4T7t4RF0LLJA+D3+AQgCJR4w1 Ju1MduQYDbOf+Xc0wXjnOx7i8GJXEs/JTSqatPRZD4PW/F+e8UHBYbcaguigSUAoecLe qN2YDP4V8XXlfh5ICHKYT5aFdv++Xidjgn7qpkwApSThi13agGoe2wslkIjkoxGifSw/ vA6g==
X-Gm-Message-State: AJaThX5+LE4o4wJJ9yp+2m3gUGoDVulZPsxNCFH6nuqKpUaMInhB3zx6 Lgm4z0FEYUcvSwtl4+XZ8p6j6urd5DbAD59jUw8f0w==
X-Google-Smtp-Source: AGs4zMYqAV4ye72dRpChvJ54VvtSpNV/WPOPF350KB3cMK0YvNJLgW1FWyJUNw/m38zQLFrbjZh/q1F7CgbtrwmsjJY=
X-Received: by 10.31.189.4 with SMTP id n4mr7048807vkf.7.1511335305667; Tue, 21 Nov 2017 23:21:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 23:21:25 -0800 (PST)
In-Reply-To: <151131990476.13215.8587456250790976923@ietfa.amsl.com>
References: <151131990476.13215.8587456250790976923@ietfa.amsl.com>
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 23:21:25 -0800
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a114dd86a07eb41055e8d2cde"
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-18.txt
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, 22 Nov 2017 07:21:49 -0000

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

It appears to me that -18 resolves Issue 43.

On Tue, Nov 21, 2017 at 7:05 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Selection of Language for Internet Media
> WG of the IETF.
>
>         Title           : Negotiating Human Language in Real-Time
> Communications
>         Author          : Randall Gellens
>         Filename        : draft-ietf-slim-negotiating-
> human-language-18.txt
>         Pages           : 16
>         Date            : 2017-11-21
>
> Abstract:
>    Users have various human (natural) language needs, abilities, and
>    preferences regarding spoken, written, and signed languages.  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.  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 media
>    attributes.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-slim-
> negotiating-human-language/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-18
> https://datatracker.ietf.org/doc/html/draft-ietf-slim-
> negotiating-human-language-18
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-
> negotiating-human-language-18
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

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


It appears to me that -18 resolves Issue 43.=C2=A0

On Tue, Nov 21, 201=
7 at 7:05 PM,  <internet-drafts@ietf.org> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Selection of Language for Internet Media W=
G of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Negotiating Human Language in Real-Time Communications

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rand=
all Gellens

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-slim-negotiating-human-language-18.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 16

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-11-21



Abstract:

=C2=A0 =C2=A0Users have various human (natural) language needs, abilities, =
and

=C2=A0 =C2=A0preferences regarding spoken, written, and signed languages.=
=C2=A0 This

=C2=A0 =C2=A0document adds new SDP media-level attributes so that when

=C2=A0 =C2=A0establishing interactive communication sessions ("calls&q=
uot;), it is

=C2=A0 =C2=A0possible to negotiate (communicate and match) the caller's=
 language

=C2=A0 =C2=A0and media needs with the capabilities of the called party.=C2=
=A0 This is

=C2=A0 =C2=A0especially important with emergency calls, where a call can be=


=C2=A0 =C2=A0handled by a call taker capable of communicating with the user=
, or a

=C2=A0 =C2=A0translator or relay operator can be bridged into the call duri=
ng

=C2=A0 =C2=A0setup, but this applies to non-emergency calls as well (as an<=
br>
=C2=A0 =C2=A0example, when calling a company call center).



=C2=A0 =C2=A0This document describes the need and a solution using new SDP =
media

=C2=A0 =C2=A0attributes.





The IETF datatracker status page for this draft is:

https://datatracker.ietf=
.org/doc/draft-ietf-slim-negotiating-human-language/



There are also htmlized versions available at:

https://tools.ietf.org/html=
/draft-ietf-slim-negotiating-human-language-18

https://datatrack=
er.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-1=
8



A diff from the previous version is available at:

https://www.ietf.or=
g/rfcdiff?url2=3Ddraft-ietf-slim-negotiating-human-language-18





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

SLIM mailing list

SLIM@ietf.org

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





--001a114dd86a07eb41055e8d2cde--


From nobody Tue Nov 21 23:28:26 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 1B5CF12EB37 for ; Tue, 21 Nov 2017 23:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 IIgv_vsH_ou2 for ; Tue, 21 Nov 2017 23:28:22 -0800 (PST)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 476E512EB43 for ; Tue, 21 Nov 2017 23:28:22 -0800 (PST)
Received: by mail-ua0-x22c.google.com with SMTP id 31so4843253uaj.6 for ; Tue, 21 Nov 2017 23:28:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=uwCkWPh5ricr1xSz7ALUluTeIaVd/PBESrLZFdZM1DI=; b=GXs6mHYwsUF78z+ltnhc1KDBmi0Pk/pWnVEdqz20iSnBjIPytn13j0/BGUg9FDyNiE 4C2foFYpCxTiSbmLOYg3fiTxGEqd8qDbnlOx+j26oYzcuk4F3BV7aV8M87eact+iS35L Y86/sM5aGKsbihGQ3tSyyWJQikwntiPUDMSXqPO84c78EDPSi2ppU/kNa3qLpknnM5Lw RwWavmBHYIYlP78XXcTgOMmCzVdUuyc3iozAYfV78tGtTtEnqyl/tq8og1sQusVXdEtn TjcP5/yYNHmxdAqDI7uM2BrRA1s//30ZJgktvkzHU24Rhewd2NDXiOSNzi4vmOnguZnA RgWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uwCkWPh5ricr1xSz7ALUluTeIaVd/PBESrLZFdZM1DI=; b=rj01j+D3Wuo8LqjmGTAnh43alxClAJU3/AS3Je6gDSlSxuFDSfZ4TmjATWVqsjeZKT bjgAamk5DpA8okv8bSRtuJMzu0pjtulD2cxXGDwUx66Q+TRKj3sFJfUBZWQtR28tpDLX PewK1LCrDcb4sI2nNCdNHqfvTYracfo5+fB0QRsE09OcYNBQlcUrPdcjZYplBxtcbqqH yNLA7lVVFPV4oWHdew03duvQG0dGHFx0JscgY34uCVrZ9roJ59IODjXSTi+SaZIGRWXk DV+KeCM8ji7VjBjvOVfOStKLG63e4R3bMrUD6TDTEl0L0WLOvE16csmUu8GbaHZ/snHQ AhqQ==
X-Gm-Message-State: AJaThX6+pe40TlfzUx7vhugbfSTI8yurxM7JbTX/+Opo93NZ+jxxwbln rXFcpiENku0O0tru57gH8zvt5x8T7HvkjigR5ILYSQ3O
X-Google-Smtp-Source: AGs4zMZ8cQl/0lgFmZc44a1C4toP1N8+NaaSZKyp5B/s/j/2gRKG83mlA0K71UW8mNYOO9B0mS5j2H1YTOOtgzVc6wI=
X-Received: by 10.159.40.169 with SMTP id d38mr9402990uad.137.1511335700892; Tue, 21 Nov 2017 23:28:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Tue, 21 Nov 2017 23:28:00 -0800 (PST)
From: Bernard Aboba 
Date: Tue, 21 Nov 2017 23:28:00 -0800
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1228c49690df055e8d4325"
Archived-At: 
Subject: [Slim] Announcement of SLIM WG Last Call on draft-ietf-slim-negotiating-human-language-18
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, 22 Nov 2017 07:28:24 -0000

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

This is an announcement of SLIM WG Last Call on
draft-ietf-slim-negotiating-human-language-18.  The draft is available for
inspection here:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-18

Since this document has already been through a WG last call as well as an
IETF last call and considerable WG discussion, this final WG last call will
last for a week.

Please post your last comments to the SLIM WG mailing list by November 30,
2017.

The SLIM WG also requests that participants disclose IPR relating to
draft-ietf-slim-negotiating-human-language-18 by November 30, 2017.

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


This is an announcement of SLIM WG Last Call on draft-ietf=
-slim-negotiating-human-language-18.=C2=A0 The draft is available for inspe=
ction here:=C2=A0

Since this=
 document has already been through a WG last call as well as an IETF last c=
all and considerable WG discussion, this final WG last call will last for a=
 week.=C2=A0

Please post your last comments to the=
 SLIM WG mailing list by November 30, 2017.=C2=A0

=
The SLIM WG also requests that participants disclose IPR relating to draft-=
ietf-slim-negotiating-human-language-18 by November 30, 2017.=C2=A0


--94eb2c1228c49690df055e8d4325--


From nobody Wed Nov 22 08:04:00 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 CB5DC129463 for ; Wed, 22 Nov 2017 08:03:58 -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 PvDO0M9sT9Wo for ; Wed, 22 Nov 2017 08:03:51 -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 CDC6C12940E for ; Wed, 22 Nov 2017 08:03:50 -0800 (PST)
X-Halon-ID: b528e0b3-cf9e-11e7-811c-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.0.40] (unknown [217.13.240.136]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id b528e0b3-cf9e-11e7-811c-0050569116f7; Wed, 22 Nov 2017 17:03:42 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>    
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se>
Date: Wed, 22 Nov 2017 17:03:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------83B8F8D2555D1A0300BB8E11"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 16:03:59 -0000

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

Den 2017-11-22 kl. 08:17, skrev Bernard Aboba:
> Gunnar said:
>
> "A non-sign language tag with video media is interpreted as a view of 
> a speaking person"
>
> [BA] I believe that Paul pointed out that such a need can be met by 
> asking for audio with the non-sign language tag and RFC 5888 lip sync 
> grouping, with no language tag for the video.
But I explained  in later mail that the LipSync grouping is a 
technical mechanism that is not expected to be set and unset depending 
on users desire to use lip reading or not. It will likely be always 
active for products using that feature for providing good sync 
regardless of what the users plan to use the video for. So, it is not 
what we want.

What we want is an indication that the user is prepared / desires to 
have the view of a speaking person in video.
We can just define that usage of hlang in video media with non-sign 
language tags, and not relate it to any use of the audio channel 
language. ( as the dropped sentence does.)  So, please reinsert the 
dropped sentence.

  Gunnar
>
> On Tue, Nov 21, 2017 at 10:53 PM, Gunnar Hellström 
> > wrote:
>
>     Randall,
>
>     1. You dropped one sentence from the first paragraph in my latest
>     proposal:
>
>     "A non-sign language tag with video media is interpreted as a view
>     of a
>      speaking person."
>
>     It was a result of the previous discussion and reasoning, and I
>     think it should be reinserted.
>
>     2. You also changed the title proposal from " 5.4 Media, Language
>     and Modality indications" to "5.4 Usage Notes"
>
>     I think it is better to have a title that tells about the topic of
>     the paragraph. I suggest to use the title I proposed, but I can
>     accept yours if you have a good reason for the change.
>
>     Thanks,
>
>     Gunnar
>
>
>     Den 2017-11-22 kl. 03:17, skrev Bernard Aboba:
>>     Looks good to me.
>>
>>     On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens
>>     > wrote:
>>
>>         I agree.  I made a few minor editorial changes (e.g., moving
>>         some text to a new paragraph):
>>
>>         5.4.  Usage Notes
>>
>>            A sign language tag with a video media stream is
>>         interpreted as an
>>            indication for sign language in the video stream.  A non-sign
>>            language tag with a text media stream is interpreted as an
>>            indication for written language in the text stream.  A
>>         non-sign
>>            language tag with an audio media stream is interpreted as an
>>            indication for spoken language in the audio stream.
>>
>>            This document does not define any other use for language
>>         tags in
>>            video media (such as how to indicate visible captions in
>>         the video
>>            stream).
>>
>>            In the IANA registry of language subtags per BCP 47
>>         [RFC5646], a
>>            language subtag with a Type field "extlang" combined with
>>         a Prefix
>>            field value "sgn" indicates a sign language tag.  The
>>         absense of
>>            such "sgn" prefix indicates a non-sign language tag.
>>
>>            This document does not define the use of sign language
>>         tags in text
>>            or audio media.
>>
>>            This document does not define the use of language tags in
>>         media
>>            other than interactive streams of audio, video, and text
>>         (such as
>>            "message" or "application").  Such use could be supported
>>         by future
>>            work or by application agreement.
>>
>>
>>         At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:
>>
>>              Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
>>
>>                  Based on the text and comments from Gunnar, brian,
>>                 Paul, and Bernard, here is what I propose to replace
>>                 section 5.4 with:
>>
>>                  5.4. Usage Notes
>>
>>                  A sign language tag with a video stream is
>>                 interpreted as an
>>                  indication for sign language in the video stream. A
>>                 non-sign
>>                  language tag with text media is interpreted as an
>>                 indication for
>>                  written language. A non-sign language tag with audio
>>                 media is
>>                  interpreted as an indication for spoken language.
>>
>>                  In the IANA registry of language subtags per BCP 47
>>                 [RFC5646], a
>>                  language subtag with a Type field "extlang" combined
>>                 with a Prefix
>>                  field value "sgn" indicates a sign language tag. The
>>                 absense of
>>                  such "sgn" prefix indicates a non-sign language tag.
>>                 This document
>>                  does not define any other use for language tags in
>>                 video media
>>                  (such as how to indicate visible captions).
>>
>>                  This document does not define the use of sign
>>                 language tags in text
>>                  or audio media.
>>
>>                  This document does not define the use of language
>>                 tags in media
>>                  other than interactive streams of audio, video, and
>>                 text (such as
>>                  "message" or "application").
>>
>>               Good, I hope that "non-sign language" can be an
>>             accepted term.
>>              I provide a slightly modified 5.4 proposal, with a bit
>>             more consistent language in the first paragraph, and the
>>             mentioning of further work or application agreement
>>             reinserted. I think that is better than just saying that
>>             it is not defined. I also added the spoken language in
>>             video is a view of a speaker according to recent
>>             discussion in another mail.
>>              I really hope to find that we are converging now.
>>
>>              ------------------------------new text
>>             -------------------------------------------
>>              5.4 Media, Language and Modality indications
>>
>>              A sign language tag with video media is interpreted as an
>>              indication for sign language in the video stream. A non-sign
>>              language tag with text media is interpreted as an
>>             indication for
>>              written language. A non-sign language tag with audio
>>             media is
>>              interpreted as an indication for spoken language. A non-sign
>>              language tag with video media is interpreted as a view of a
>>              speaking person. This document does not define any other
>>              use for language tags in video media (such as how to
>>             indicate
>>              visible captions in the video stream).
>>
>>              In the IANA registry of language subtags per BCP 47
>>             [RFC5646], a
>>              language subtag with a Type field "extlang" combined
>>             with a Prefix
>>              field value "sgn" indicates a sign language tag. The
>>             absense of
>>              such "sgn" prefix indicates a non-sign language tag.
>>
>>              This document does not define the use of sign language
>>             tags in text
>>              or audio media. This document does not define the use of
>>             language tags in media
>>              other than interactive streams of audio, video, and text
>>             (such as
>>              "message" or "application"). Such use may be supported
>>             by further work
>>              or application specific agreements.
>>
>>
>>             ---------------------------------------------------------------------------------------------
>>              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
>>             
>>
>>
>>
>>         -- 
>>         Randall Gellens
>>         Opinions are personal;    facts are suspect;    I speak for
>>         myself only
>>         -------------- Randomly selected tag: ---------------
>>         Never knock the way the other cat swings.
>>                                  --Neal Cassady
>>
>>
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     gunnar.hellstrom@omnitor.se 
>     +46 708 204 288
>
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


--------------83B8F8D2555D1A0300BB8E11
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2017-11-22 kl. 08:17, skrev Bernard Aboba:

    

      
Gunnar said: 
        


        

        
"A
            non-sign language tag with video media is interpreted as a
            view of a speaking person"

        


        

        
[BA] I believe that Paul pointed out that such a need can
          be met by asking for audio with the non-sign language tag and
          RFC 5888 lip sync grouping, with no language tag for the
          video. 

        

      

    

    <GH>But I explained  in later mail that the LipSync grouping
    is a technical mechanism that is not expected to be set and unset
    depending on users desire to use lip reading or not. It will likely
    be always active for products using that feature for providing good
    sync regardless of what the users plan to use the video for. So, it
    is not what we want. 

    

    What we want is an indication that the user is prepared / desires to
    have the view of a speaking person in video. 

    We can just define that usage of hlang in video media with non-sign
    language tags, and not relate it to any use of the audio channel
    language. ( as the dropped sentence does.)  So, please reinsert the
    dropped sentence. 

    

     Gunnar

    

      


        
On Tue, Nov 21, 2017 at 10:53 PM,
          Gunnar Hellström <gunnar.hellstrom@omnitor.se>
          wrote:

          

            

              
Randall, 

              

              
1. You dropped one sentence from the first paragraph in
                my latest proposal:

              
                
"A non-sign language tag with video media is
                  interpreted as a view of a

                   speaking person."

              
              
It was a result of the previous discussion and
                reasoning, and I think it should be reinserted. 

              

              
2. You also changed the title proposal from " 5.4
                Media, Language and Modality indications" to "5.4 Usage
                Notes"

              
I think it is better to have a title that tells about
                the topic of the paragraph. I suggest to use the title I
                proposed, but I can accept yours if you have a good
                reason for the change.

              
Thanks,

              
Gunnar

              

              

                
 

                  
Den
                    2017-11-22 kl. 03:17, skrev Bernard Aboba:

                  

                  

                    
Looks good to me. 

                    


                      
On Tue, Nov 21, 2017 at
                        3:17 PM, Randall Gellens <rg+ietf@randy.pensive.org>
                        wrote:

                        
I agree.  I made a few
                          minor editorial changes (e.g., moving some
                          text to a new paragraph):

                          

                          5.4.  Usage Notes

                          

                             A sign language tag with a video media
                          stream is interpreted as an

                               indication for sign language in the video
                            stream.  A non-sign

                              language tag with a text media
                          stream is interpreted as an

                             indication for written language in the text
                          stream.  A non-sign

                             language tag with an audio media stream is
                          interpreted as an

                             indication for spoken language in the audio
                          stream.

                            

                               This document does not define any other
                            use for language tags in

                               video media (such as how to indicate
                            visible captions in the video

                               stream).

                            

                               In the IANA registry of language subtags
                            per BCP 47 [RFC5646], a

                               language subtag with a Type field
                            "extlang" combined with a Prefix

                               field value "sgn" indicates a sign
                            language tag.  The absense of

                               such "sgn" prefix indicates a non-sign
                            language tag.

                            

                               This document does not define the use of
                            sign language tags in text

                               or audio media.

                            

                               This document does not define the use of
                            language tags in media

                               other than interactive streams of audio,
                            video, and text (such as

                              "message" or "application").  Such
                          use could be supported by future

                             work or by application agreement.
                          

                            


                              

                              At 11:50 PM +0100 11/21/17, Gunnar
                              Hellström wrote:

                              

                            

                          

                          

                            

                              
  Den
                                2017-11-21 kl. 23:08, skrev Randall
                                Gellens:

                                

                                
  Based on the
                                  text and comments from Gunnar, brian,
                                  Paul, and Bernard, here is what I
                                  propose to replace section 5.4 with:

                                  

                                   5.4. Usage Notes

                                  

                                   A sign language tag with a video
                                  stream is interpreted as an

                                   indication for sign language in the
                                  video stream. A non-sign

                                   language tag with text media is
                                  interpreted as an indication for

                                   written language. A non-sign language
                                  tag with audio media is

                                   interpreted as an indication for
                                  spoken language.

                                  

                                   In the IANA registry of language
                                  subtags per BCP 47 [RFC5646], a

                                   language subtag with a Type field
                                  "extlang" combined with a Prefix

                                   field value "sgn" indicates a sign
                                  language tag. The absense of

                                   such "sgn" prefix indicates a
                                  non-sign language tag. This document

                                   does not define any other use for
                                  language tags in video media

                                   (such as how to indicate visible
                                  captions).

                                  

                                   This document does not define the use
                                  of sign language tags in text

                                   or audio media.

                                  

                                   This document does not define the use
                                  of language tags in media

                                   other than interactive streams of
                                  audio, video, and text (such as

                                   "message" or "application").

                                  

                                

                                 <GH> Good, I hope that "non-sign
                                language" can be an accepted term.

                                 I provide a slightly modified 5.4
                                proposal, with a bit more consistent
                                language in the first paragraph, and the
                                mentioning of further work or
                                application agreement reinserted. I
                                think that is better than just saying
                                that it is not defined. I also added the
                                spoken language in video is a view of a
                                speaker according to recent discussion
                                in another mail.

                                 I really hope to find that we are
                                converging now.

                                

                                 ------------------------------new
                                text -------------------------------------------

                                 5.4 Media, Language and Modality
                                indications

                                

                                 A sign language tag with video media is
                                interpreted as an

                                 indication for sign language in the
                                video stream. A non-sign

                                 language tag with text media is
                                interpreted as an indication for

                                 written language. A non-sign language
                                tag with audio media is

                                 interpreted as an indication for spoken
                                language. A non-sign

                                 language tag with video media is
                                interpreted as a view of a

                                 speaking person. This document does not
                                define any other

                                 use for language tags in video media
                                (such as how to indicate

                                 visible captions in the video stream).

                                

                                 In the IANA registry of language
                                subtags per BCP 47 [RFC5646], a

                                 language subtag with a Type field
                                "extlang" combined with a Prefix

                                 field value "sgn" indicates a sign
                                language tag. The absense of

                                 such "sgn" prefix indicates a non-sign
                                language tag.

                                

                                 This document does not define the use
                                of sign language tags in text

                                 or audio media. This document does not
                                define the use of language tags in media

                                 other than interactive streams of
                                audio, video, and text (such as

                                 "message" or "application"). Such use
                                may be supported by further work

                                 or application specific agreements.

                                

                                

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

                                 Gunnar

                                 --

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

                                 Gunnar Hellström

                                 Omnitor

                              

                            

                             <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se

                             +46 708 204 288

                            

                             _______________________________________________

                             SLIM mailing list

                             SLIM@ietf.org

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

                          

                           

                            

                            -- 

                            Randall Gellens

                            Opinions are personal;    facts are
                            suspect;    I speak for myself only

                            -------------- Randomly selected tag:
                            ---------------

                           Never knock the way the other cat
                          swings.

                                                   --Neal Cassady

                        

                      

                      

                    

                  

                  

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

                

              

            

          

        

        

      

      

      

      

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


    

    

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

  


--------------83B8F8D2555D1A0300BB8E11--


From nobody Wed Nov 22 08:20:38 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 5ECEB129463 for ; Wed, 22 Nov 2017 08:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 w04mHqSyIyBj for ; Wed, 22 Nov 2017 08:20:35 -0800 (PST)
Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBAE1243F6 for ; Wed, 22 Nov 2017 08:20:35 -0800 (PST)
Received: by mail-pl0-x235.google.com with SMTP id 62so1003247plc.2 for ; Wed, 22 Nov 2017 08:20:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jt5MvR9h0pRUSuM/be81PLqq5cUPf+9w+6fH6bDfTG0=; b=BtK8mrgbCfmSRwQYB7C5zPuWmd8C0i2k9bHwKpsMVBZ0wloWIMbWZNj+n6cNBfG5At rOCU3G3e/cwT4OGdQHc3DSJEIQf453pWu0D83u+b5AQz5RQ8yXXuM4yU+b0saDzBui/1 AaGqxm0q09lg5ro6wgvagI0NRcCH9PIL08SDa3nljdak2czwKn2RRa4e5slU/fp4NI1v yVFZaBu2TBOo8932YVDbxI72z9WSI9fxdm5uevYXKptjlOsZTMEEuqeUTQMP0F+xyl5A AAYc2hXzyVBjMdBtjslaFLbxSzenfNdvupnf679omPkuTDckRheUsYY+IM+oRrwkiqvu xY9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jt5MvR9h0pRUSuM/be81PLqq5cUPf+9w+6fH6bDfTG0=; b=X8ucrOxjslX2RgJB9VZPRO5eBEpL91QyAaoynwWD2Xx49uTM5w8HcIyfroS2Lox4xB lWnBkmsoi3r8j0hPIsGkTEaPcT2ht+OSCT/XFlQ4mSY2cXhJFFc52b5tVxflaSNbRbP0 rXS/XRx6r4WBMglNkS2dJajiOtGD7sBstQdfF2bXiQayJ0lzeJVejfTLCt61Q7RtvtiA yifmtTTuqzKin2Cq3a43cGOil6xf0PnG0xz790ohie2HlqlgOxLqsCz72R1aRiNccJvG ImL7CUeTwlSGQXb6bvnbdOmToB3lRqtfBTPdwaJk8VspaTQsCvMKGEk8zjl33bJVTdVb ThdQ==
X-Gm-Message-State: AJaThX6/bdx2gbSUHLtdhnLHNPle8t+4kcCw6Nyq/9pwF5poe038WW1G xeXmqWPFUQ9+XllK6pSY1lY=
X-Google-Smtp-Source: AGs4zMbNIQCTaBl7Kg5VSWSTiif4LF7U2Px/LrD7vW+09qvJ5mZldO31jKnpXTsDdwH3EX97xAU2Fg==
X-Received: by 10.159.216.131 with SMTP id s3mr21650596plp.432.1511367635090;  Wed, 22 Nov 2017 08:20:35 -0800 (PST)
Received: from [192.168.1.104] (c-98-225-39-241.hsd1.wa.comcast.net. [98.225.39.241]) by smtp.gmail.com with ESMTPSA id 68sm31243920pfk.162.2017.11.22.08.20.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 08:20:34 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (15B202)
In-Reply-To: <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se>
Date: Wed, 22 Nov 2017 08:20:33 -0800
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 16:20:37 -0000

On Nov 22, 2017, at 8:03 AM, Gunnar Hellstr=C3=B6m  wrote:

> What we want is an indication that the user is prepared / desires to have t=
he view of a speaking person in video.=20

The problem is that a written/spoken tag in video is ambiguous because it co=
uld also represent a desire for captioning. So there is a need to distinguis=
h spoken from written language. We have not had consensus on how to do that,=
 in general.=20=


From nobody Wed Nov 22 08: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 7924C12946A for ; Wed, 22 Nov 2017 08:50:41 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gbvTA_ycocXk for ; Wed, 22 Nov 2017 08:50:40 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6765B129469 for ; Wed, 22 Nov 2017 08:50:40 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Nov 2017 08:50:46 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Nov 2017 08:50:36 -0800
To: Bernard Aboba , Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  
From: Randall Gellens 
Cc: slim@ietf.org, Paul Kyzivat , Brian Rosen 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 16:50:41 -0000

If we need to specify how to request a video stream for a view of the 
speaking person, we could go back to the old text of saying a video 
stream without a language attribute, but I think we don't need to 
specify it in this document.  We've always said that we want to 
produce a simple mechanism that can be more easily deployed, so we 
can gain operational experience to inform an update later.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If God lived on Earth, people would knock out all His windows.
                                             --Yiddish saying


From nobody Wed Nov 22 12:39:10 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 2AAD4127873 for ; Wed, 22 Nov 2017 12:39:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level: 
X-Spam-Status: No, score=-4.799 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 dNxK29Pf6oaV for ; Wed, 22 Nov 2017 12:39:03 -0800 (PST)
Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81A212EB61 for ; Wed, 22 Nov 2017 12:39:02 -0800 (PST)
Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-5-imp with bizsmtp id d8ez1w0033hDt9d018ezoB; Wed, 22 Nov 2017 20:38:59 +0000
X-Originating-IP: [81.97.229.170]
X-Authenticated-User: drageke@ntlworld.com
X-Spam: 0
X-Authority: v=2.1 cv=Ku2wojiN c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=x7bEGLp0ZPQA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=2XxDvuMUAAAA:8 a=48vgC7mUAAAA:8 a=PIZp1JHyTn1YxsQiDqgA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=r8V8T7LFwPy1_rBly1cA:9 a=AIL6ol6lhOnPS5YB:21 a=_W_S_7VecoQA:10 a=IfFLB24aErD9igj8xSD1:22 a=w1C3t2QeGrPiZgrLijVG:22
To: slim@ietf.org
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>  
From: Keith Drage 
Message-ID: <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com>
Date: Wed, 22 Nov 2017 20:39:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------30562DAC9FCBF17497B7C222"
Content-Language: en-US
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1511383139; bh=qq7d5nW2upoqXf0n7a2rBDs2RBdZDItJq7JQlgrQ/Gs=; h=Subject:To:References:From:Date:In-Reply-To; b=dJ5lGc3DxEqsYx30wRh+jkqN3qxn7p5st+s/3TObkcZcmCFbA63Z7YVqJ8uREibVO NpYZ7CoKYPAfXZwdM2R5mKd+ARYwt5Rw6mQjRNH2XgG+s0aVfBP1uvx+ezQif+u+9h WYZQ5Ip7OGV0wxJylhK/e8OLwc+RnUQR2TkWqxFC8//6nToWDgAkSPmXdy/v2ggiIc u9wHdCEFcv1Oan0YzlllSOw2MfOuQgbMuDaoMW2xFOyYST2Q7CXKFtqBBTHNUy2dOs Hm2QXJU9BBF4pqTeB5q+oWbVovCH7E0+qa8yBO9mumR8d3EI4TzddbyRCTI4ytLXvp ptgGhPPyq+LKQ==
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 20:39:08 -0000

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

Why do we keep having to use this construct "non-sign", which in itself 
is entirely meaningless. Surely in this case we are talking about a 
either the absence of a language tag, or the absence of "sgn" within a 
language tag. Why don't we just talk about the absence of "sgn" where 
necessary.

As an aside I note elsewhere in the document we talk about 
"non-emergency calls", which should mean "a call for a non-emergency". 
The correct opposite to emergency call would be "call that is not 
related to an emergency".

There are several other "non-" instances in the document that are 
equally meaningless. I assume "non-realtime xxx" is not intended to mean 
"unrealtime xxx", but rather, "xxx that is not realtime".

Keith

On 22-Nov-17 2:17 AM, Bernard Aboba wrote:
> Looks good to me.
>
> On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens 
> > wrote:
>
>     I agree. I made a few minor editorial changes (e.g., moving some
>     text to a new paragraph):
>
>     5.4.  Usage Notes
>
>        A sign language tag with a video media stream is interpreted as an
>        indication for sign language in the video stream.  A non-sign
>        language tag with a text media stream is interpreted as an
>        indication for written language in the text stream.  A non-sign
>        language tag with an audio media stream is interpreted as an
>        indication for spoken language in the audio stream.
>
>        This document does not define any other use for language tags in
>        video media (such as how to indicate visible captions in the video
>        stream).
>
>        In the IANA registry of language subtags per BCP 47 [RFC5646], a
>        language subtag with a Type field "extlang" combined with a Prefix
>        field value "sgn" indicates a sign language tag.  The absense of
>        such "sgn" prefix indicates a non-sign language tag.
>
>        This document does not define the use of sign language tags in text
>        or audio media.
>
>        This document does not define the use of language tags in media
>        other than interactive streams of audio, video, and text (such as
>        "message" or "application").  Such use could be supported by future
>        work or by application agreement.
>
>
>     At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:
>
>          Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
>
>              Based on the text and comments from Gunnar, brian, Paul,
>             and Bernard, here is what I propose to replace section 5.4
>             with:
>
>              5.4. Usage Notes
>
>              A sign language tag with a video stream is interpreted as an
>              indication for sign language in the video stream. A non-sign
>              language tag with text media is interpreted as an
>             indication for
>              written language. A non-sign language tag with audio media is
>              interpreted as an indication for spoken language.
>
>              In the IANA registry of language subtags per BCP 47
>             [RFC5646], a
>              language subtag with a Type field "extlang" combined with
>             a Prefix
>              field value "sgn" indicates a sign language tag. The
>             absense of
>              such "sgn" prefix indicates a non-sign language tag. This
>             document
>              does not define any other use for language tags in video
>             media
>              (such as how to indicate visible captions).
>
>              This document does not define the use of sign language
>             tags in text
>              or audio media.
>
>              This document does not define the use of language tags in
>             media
>              other than interactive streams of audio, video, and text
>             (such as
>              "message" or "application").
>
>           Good, I hope that "non-sign language" can be an accepted
>         term.
>          I provide a slightly modified 5.4 proposal, with a bit more
>         consistent language in the first paragraph, and the mentioning
>         of further work or application agreement reinserted. I think
>         that is better than just saying that it is not defined. I also
>         added the spoken language in video is a view of a speaker
>         according to recent discussion in another mail.
>          I really hope to find that we are converging now.
>
>          ------------------------------new text
>         -------------------------------------------
>          5.4 Media, Language and Modality indications
>
>          A sign language tag with video media is interpreted as an
>          indication for sign language in the video stream. A non-sign
>          language tag with text media is interpreted as an indication for
>          written language. A non-sign language tag with audio media is
>          interpreted as an indication for spoken language. A non-sign
>          language tag with video media is interpreted as a view of a
>          speaking person. This document does not define any other
>          use for language tags in video media (such as how to indicate
>          visible captions in the video stream).
>
>          In the IANA registry of language subtags per BCP 47 [RFC5646], a
>          language subtag with a Type field "extlang" combined with a
>         Prefix
>          field value "sgn" indicates a sign language tag. The absense of
>          such "sgn" prefix indicates a non-sign language tag.
>
>          This document does not define the use of sign language tags
>         in text
>          or audio media. This document does not define the use of
>         language tags in media
>          other than interactive streams of audio, video, and text (such as
>          "message" or "application"). Such use may be supported by
>         further work
>          or application specific agreements.
>
>
>         ---------------------------------------------------------------------------------------------
>          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
>         
>
>
>
>     -- 
>     Randall Gellens
>     Opinions are personal;    facts are suspect;    I speak for myself
>     only
>     -------------- Randomly selected tag: ---------------
>     Never knock the way the other cat swings.
>                              --Neal Cassady
>
>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim



--------------30562DAC9FCBF17497B7C222
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Why do we keep having to use this
      construct "non-sign", which in itself is entirely meaningless.
      Surely in this case we are talking about a either the absence of a
      language tag, or the absence of "sgn" within a language tag. Why
      don't we just talk about the absence of "sgn" where necessary.

      

      As an aside I note elsewhere in the document we talk about
      "non-emergency calls", which should mean "a call for a
      non-emergency". The correct opposite to emergency call would be
      "call that is not related to an emergency".

      

      There are several other "non-" instances in the document that are
      equally meaningless. I assume "non-realtime xxx" is not intended
      to mean "unrealtime xxx", but rather, "xxx that is not realtime".

      

      Keith

      

      On 22-Nov-17 2:17 AM, Bernard Aboba wrote:

    

    

      
Looks good to me. 

      


        
On Tue, Nov 21, 2017 at 3:17 PM,
          Randall Gellens <rg+ietf@randy.pensive.org>
          wrote:

          
I agree. 
            I made a few minor editorial changes (e.g., moving some text
            to a new paragraph):

            

            5.4.  Usage Notes

            

               A sign language tag with a video media stream is
            interpreted as an

                 indication for sign language in the video stream.  A
              non-sign

            
               language tag with a text media stream is interpreted as
            an

               indication for written language in the text stream.  A
            non-sign

               language tag with an audio media stream is interpreted as
            an

               indication for spoken language in the audio stream.

              

                 This document does not define any other use for
              language tags in

                 video media (such as how to indicate visible captions
              in the video

                 stream).

              

                 In the IANA registry of language subtags per BCP 47
              [RFC5646], a

                 language subtag with a Type field "extlang" combined
              with a Prefix

                 field value "sgn" indicates a sign language tag.  The
              absense of

                 such "sgn" prefix indicates a non-sign language tag.

              

                 This document does not define the use of sign language
              tags in text

                 or audio media.

              

                 This document does not define the use of language tags
              in media

                 other than interactive streams of audio, video, and
              text (such as

            
               "message" or "application").  Such use could be supported
            by future

               work or by application agreement.
            

              


                

                At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:

                

              

            

            

              

                

                   Den 2017-11-21 kl. 23:08, skrev Randall Gellens:

                  

                  

                     Based on the text and comments from Gunnar, brian,
                    Paul, and Bernard, here is what I propose to replace
                    section 5.4 with:

                    

                     5.4. Usage Notes

                    

                     A sign language tag with a video stream is
                    interpreted as an

                     indication for sign language in the video stream. A
                    non-sign

                     language tag with text media is interpreted as an
                    indication for

                     written language. A non-sign language tag with
                    audio media is

                     interpreted as an indication for spoken language.

                    

                     In the IANA registry of language subtags per BCP 47
                    [RFC5646], a

                     language subtag with a Type field "extlang"
                    combined with a Prefix

                     field value "sgn" indicates a sign language tag.
                    The absense of

                     such "sgn" prefix indicates a non-sign language
                    tag. This document

                     does not define any other use for language tags in
                    video media

                     (such as how to indicate visible captions).

                    

                     This document does not define the use of sign
                    language tags in text

                     or audio media.

                    

                     This document does not define the use of language
                    tags in media

                     other than interactive streams of audio, video, and
                    text (such as

                     "message" or "application").

                    

                  

                   <GH> Good, I hope that "non-sign language" can
                  be an accepted term.

                   I provide a slightly modified 5.4 proposal, with a
                  bit more consistent language in the first paragraph,
                  and the mentioning of further work or application
                  agreement reinserted. I think that is better than just
                  saying that it is not defined. I also added the spoken
                  language in video is a view of a speaker according to
                  recent discussion in another mail.

                   I really hope to find that we are converging now.

                  

                   ------------------------------new text
                  -------------------------------------------

                   5.4 Media, Language and Modality indications

                  

                   A sign language tag with video media is interpreted
                  as an

                   indication for sign language in the video stream. A
                  non-sign

                   language tag with text media is interpreted as an
                  indication for

                   written language. A non-sign language tag with audio
                  media is

                   interpreted as an indication for spoken language. A
                  non-sign

                   language tag with video media is interpreted as a
                  view of a

                   speaking person. This document does not define any
                  other

                   use for language tags in video media (such as how to
                  indicate

                   visible captions in the video stream).

                  

                   In the IANA registry of language subtags per BCP 47
                  [RFC5646], a

                   language subtag with a Type field "extlang" combined
                  with a Prefix

                   field value "sgn" indicates a sign language tag. The
                  absense of

                   such "sgn" prefix indicates a non-sign language tag.

                  

                   This document does not define the use of sign
                  language tags in text

                   or audio media. This document does not define the use
                  of language tags in media

                   other than interactive streams of audio, video, and
                  text (such as

                   "message" or "application"). Such use may be
                  supported by further work

                   or application specific agreements.

                  

                  

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

                   Gunnar

                   --

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

                   Gunnar Hellström

                   Omnitor

                

              

               <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se

               +46 708 204 288

              

               _______________________________________________

               SLIM mailing list

               SLIM@ietf.org

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

            

            
              

              

              -- 

              Randall Gellens

              Opinions are personal;    facts are suspect;    I speak
              for myself only

              -------------- Randomly selected tag: ---------------

            
            Never knock the way the other cat swings.

                                     --Neal Cassady

          

        

        

      

      

      

      

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


    

    


    

  


--------------30562DAC9FCBF17497B7C222--


From nobody Wed Nov 22 13:14:29 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 715D9129BC6 for ; Wed, 22 Nov 2017 13:14:28 -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 hpTXU7ai6AvO for ; Wed, 22 Nov 2017 13:14:26 -0800 (PST)
Received: from bin-vsp-out-01.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 33C4312EB5C for ; Wed, 22 Nov 2017 13:14:26 -0800 (PST)
X-Halon-ID: 12dcb9c2-cfca-11e7-aaf5-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 12dcb9c2-cfca-11e7-aaf5-005056917a89; Wed, 22 Nov 2017 22:14:07 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Wed, 22 Nov 2017 22:14:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 21:14:28 -0000

Den 2017-11-22 kl. 17:20, skrev Bernard Aboba:
> On Nov 22, 2017, at 8:03 AM, Gunnar Hellström  wrote:
>
>> What we want is an indication that the user is prepared / desires to have the view of a speaking person in video.
> The problem is that a written/spoken tag in video is ambiguous because it could also represent a desire for captioning. So there is a need to distinguish spoken from written language. We have not had consensus on how to do that, in general.
Bernard,

We had a reasoning yesterday that it is so unusual to provide text in a 
conversational video call in the video media stream that we could leave 
that usage undefined (it was used as mixed into the video image from the 
sending side in the early 2000s, and it is also possible to send text 
coded text elements in RFC 3640 MPEG4 video coding for presentation in 
the receiving end, but the impression is that these methods are not used 
nowadays in conversational calls) That leaves the only practically used 
case for non-sign language in video media in conversational calls be for 
a view of spoken language.
Randall introduced that view (about captions in video not being used in 
conversational calls) and I agreed. I know that is not total consensus, 
but there were at least not any declared conflicting views.

There are use cases for the use of a view of a speaking person in video.

It would be good if this reasoning makes you change your mind and check 
if we can have consensus for inserting the dropped sentence.

If not, I will stop arguing for that and accept that we need to take the 
effort to define how to indicate this use case at a later stage. The 
rest of section 5.4 is good now and explicitly allows further work and 
application agreements.

Gunnar

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


From nobody Wed Nov 22 15:05:00 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 EFFDE129BDB for ; Wed, 22 Nov 2017 15:04:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 FN7NtD-_Mx2A for ; Wed, 22 Nov 2017 15:04:57 -0800 (PST)
Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 446A612960D for ; Wed, 22 Nov 2017 15:04:56 -0800 (PST)
Received: by mail-pl0-x233.google.com with SMTP id z3so1580999plh.9 for ; Wed, 22 Nov 2017 15:04:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGUfs/pe5jdmPSnSQREU2a9y3VbhpPOUTHqY7Cyw73U=; b=hvkRByGrHvgstpOJZL4691TW6EXIWoony9ri6Tu6Q/dEq9ymCF/a01l5IHgDIhjgAS 1vycYedsDrhalEkf2KzTHKprYMiQFwBzw2+mMc8ygj30FCidM6TpBifzikTMJzWaZOkI /lnMxZz5fYWRTWh4Bf5xoxGJv1JczgB1yzCJf1TKPAqXmUhCVbBKwsJZHDFEsSchwKVM gFSna1MsNUWTkINK03ooNsNfh0kv5aFh6gFrIfnqohngSAHkh0ms8GhWaT/gnBHLEioh R2CHpbGbxpHA9pFAt7LGKqhislpNruxOliWhGjipkWRe/nrEoZYHJMr1QEAL7hgJ1o5H ZjqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGUfs/pe5jdmPSnSQREU2a9y3VbhpPOUTHqY7Cyw73U=; b=r/2mHZChLwoxtEW3Oi0J3t26xBy/v83wjKCRtdcX6iIG7DRBY/oPMWTKogNO7fNUTB Vub30aXG4UHDa3hoR4pV6Sf7bI1sO+2bcL3hXkwWAOmbLmVrHCfWWExWrbF4UQVrNAn1 OqFMuyL1rQCsC2TVP6hyB3uloRGQc0lk95KULlcL8IhYrlCbiHF+FyryHYUxLr/yN2BD wxbatC6foJOFpkMxDzaJYxAR1iReyqSyqwmCoozeAXu5J8HEBIgalyE6HYBw/fLZESnP 3j3amek+p6syWfFMFMiEwgkk8M1ZyBEoPC4xStObl/9+MVWWDgFshZGoAes2AJbalFQr ipbw==
X-Gm-Message-State: AJaThX5nh+6FiNxBEnIZBmOwrdOCfCq1tnKpfpxuN7jwqNp1s6Sggo7l R2BS81tksgWMNIZ32tKic2nUfOXa
X-Google-Smtp-Source: AGs4zMYQZWXQzr1KZxQWobu5w2QKSVveLRfdhOwD6QX5yj9Js+/xLfFy4F///ZjZ8A1szTZrkrOAsQ==
X-Received: by 10.84.131.41 with SMTP id 38mr13036921pld.149.1511391896214; Wed, 22 Nov 2017 15:04:56 -0800 (PST)
Received: from [192.168.1.101] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id s81sm29277486pfg.60.2017.11.22.15.04.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 15:04:55 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (15B202)
In-Reply-To: 
Date: Wed, 22 Nov 2017 15:04:54 -0800
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DF564B4-88CD-4758-8F84-39BFCBD72B0E@gmail.com>
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com> 
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 23:04:59 -0000

On Nov 22, 2017, at 1:14 PM, Gunnar Hellstr=C3=B6m  wrote:
>>=20
> Randall introduced that view (about captions in video not being used in co=
nversational calls) and I agreed. I know that is not total consensus, but th=
ere were at least not any declared conflicting views.

[BA] With speech recognition APIs now approaching realtime performance it is=
 becoming feasible to do captioning in realtime video. There are situations (=
e.g. recordings of classes posted online) where captioning is required by re=
gulators, and it is more efficient and inclusive to do captioning during the=
 class and record it than to require students to wait for postprocessing to a=
dd captions.



>=20
> There are use cases for the use of a view of a speaking person in video.
>=20
> It would be good if this reasoning makes you change your mind and check if=
 we can have consensus for inserting the dropped sentence.
>=20
> If not, I will stop arguing for that and accept that we need to take the e=
ffort to define how to indicate this use case at a later stage. The rest of s=
ection 5.4 is good now and explicitly allows further work and application ag=
reements.
>=20
> Gunnar
>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>=20


From nobody Wed Nov 22 15:47: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 9568E1200F1 for ; Wed, 22 Nov 2017 15:47:27 -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 TNTQH0eqFKdH for ; Wed, 22 Nov 2017 15:47:25 -0800 (PST)
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 43019126B6E for ; Wed, 22 Nov 2017 15:47:25 -0800 (PST)
X-Halon-ID: 731efa5b-cfdf-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 731efa5b-cfdf-11e7-96ae-005056917f90; Thu, 23 Nov 2017 00:47:08 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>  <2DF564B4-88CD-4758-8F84-39BFCBD72B0E@gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <584cf317-ad5e-3261-ba88-8409610899d7@omnitor.se>
Date: Thu, 23 Nov 2017 00:47:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2DF564B4-88CD-4758-8F84-39BFCBD72B0E@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 23:47:27 -0000

Den 2017-11-23 kl. 00:04, skrev Bernard Aboba:
> On Nov 22, 2017, at 1:14 PM, Gunnar Hellström  wrote:
>> Randall introduced that view (about captions in video not being used in conversational calls) and I agreed. I know that is not total consensus, but there were at least not any declared conflicting views.
> [BA] With speech recognition APIs now approaching realtime performance it is becoming feasible to do captioning in realtime video. There are situations (e.g. recordings of classes posted online) where captioning is required by regulators, and it is more efficient and inclusive to do captioning during the class and record it than to require students to wait for postprocessing to add captions.
Yes, I agree completely that speech recognition is a reality for 
real-time captioning today. But do you know implementations that 
transmit it as part of a video media stream? What coding?
>
>
>
>> There are use cases for the use of a view of a speaking person in video.
>>
>> It would be good if this reasoning makes you change your mind and check if we can have consensus for inserting the dropped sentence.
>>
>> If not, I will stop arguing for that and accept that we need to take the effort to define how to indicate this use case at a later stage. The rest of section 5.4 is good now and explicitly allows further work and application agreements.
>>
>> Gunnar
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

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


From nobody Wed Nov 22 15:57: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 C7905126DFB for ; Wed, 22 Nov 2017 15:57:21 -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.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kzYFVVgdO7MG for ; Wed, 22 Nov 2017 15:57:20 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D2BB1126B6E for ; Wed, 22 Nov 2017 15:57:20 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 22 Nov 2017 15:57:27 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>     <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 22 Nov 2017 15:52:58 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  
From: Randall Gellens 
Cc: slim@ietf.org, Brian Rosen , Bernard Aboba 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 22 Nov 2017 23:57:22 -0000

At 10:14 PM +0100 11/22/17, Gunnar Hellstr=F6m wrote:

>  explicitly allows further work and application agreements

Just as an aside, the text explicitly allowing=20
for such is unnecessary; if the draft did not=20
prohibit it, it would be permitted.  There's also=20
no harm in the text explicitly permitting it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Dogs believe they are human. Cats believe they are God.


From nobody Wed Nov 22 16:28: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 F1313126C22 for ; Wed, 22 Nov 2017 16:28:51 -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 042quI2Q633e for ; Wed, 22 Nov 2017 16:28:50 -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 C7B6F126B6E for ; Wed, 22 Nov 2017 16:28:49 -0800 (PST)
X-Halon-ID: 3d6f01eb-cfe5-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 3d6f01eb-cfe5-11e7-96ae-005056917f90; Thu, 23 Nov 2017 01:28:35 +0100 (CET)
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
To: slim@ietf.org, Bernard Aboba 
References: 
Message-ID: <4af2a672-8625-99e7-288f-068399b33b63@omnitor.se>
Date: Thu, 23 Nov 2017 01:28:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Slim] I-D Action: draft-hellstrom-slim-modality-grouping-00.txt
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, 23 Nov 2017 00:28:52 -0000

Bernard,

Your indication that request for captions is very realistic nowadays 
because of the progress in speech recognition reminded me that I have 
not yet got any comments on draft-hellstrom-slim-modality-grouping.

Its mechanism is needed for example to request or offer text captions of 
spoken language.

It is relatively self sustained so it can be discussed, reviewed and 
progressed even if we are waiting for progress of the slim real-time draft.

I got promises that it would be reviewed by slim members, even if mmusic 
would also be a possibility.

Can we handle it in slim? Please review.

/Gunnar


Den 2017-07-03 kl. 20:23, skrev Gunnar Hellstrm:
> A new draft is available, replacing draft-hellstrom-language-grouping-00
> Just a few minor changes. They are:
> -A new file name indicating its relation to the SLIM wg.
> -A shorter abstract.
> -More polite IANA registration request.
> -A section about changes from earlier version.
>
> Regards
> Gunnar
> --------------------------------------------------------
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
>  Title : Human Language Modality Grouping Semantics 
> in Session Description Protocol
>  Author : Gunnar Hellstrom
> Filename : draft-hellstrom-slim-modality-grouping-00.txt
> Pages : 10
> Date : 2017-07-03
>
> Abstract:
>  When setting up a real-time communication session, there may be a
>  need to indicate priority for which media to use for language
>  communications or a need to indicate preference for receiving the
>  same language content simultaneously in two modalities. This
>  document defines the semantics for grouping media for such purposes
>  in the Session Description Protocol (SDP). The semantics defined in
>  this document are based on the SDP Grouping Framework. Applications
>  are for example negotiation the most suitable common modality or
>  modalities for language communications in a real-time session. The
>  indications are specified for the sending and receiving direction
>  separately.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hellstrom-slim-modality-grouping/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hellstrom-slim-modality-grouping-00
> https://datatracker.ietf.org/doc/html/draft-hellstrom-slim-modality-grouping-00 
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

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


From nobody Wed Nov 22 18:02:17 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 624D0124B0A for ; Wed, 22 Nov 2017 18:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ns7JuOHOFEuW for ; Wed, 22 Nov 2017 18:02:13 -0800 (PST)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D357A1205D3 for ; Wed, 22 Nov 2017 18:02:13 -0800 (PST)
Received: by mail-pg0-x22f.google.com with SMTP id r12so13358455pgu.10 for ; Wed, 22 Nov 2017 18:02:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tACN+7jJ+Kh2Tf2eJTxhD3lvs/6wWhho7rjnAyWr7Rs=; b=ItjNRGf9+iRzAVFlrPLqDJsjL4oktuMjCiBf77Lv7uBMdL2ca+iE1Ub81hTebuqpni 2gnuwug4RfCp1i9bx9q2UuOU2zXITABYWjuHVJ5Y63c66/mZ6VGtYeJ2qmiwE+URAKs7 +DlBxoR64UVe7AB4RqCYcAjjhtCqnZ9iYHcmm7vowpNDkPSwfuIpDITVNDRBU/8y1Ggh BEhVERMdx0xhoy5UzxGHKb6vq8gfBnSqZvD59abeTV9XClIh8JFjs2CV2zaHCkl4Clhl 4MmGOVkyhaA9wTzEjS/3u2ICL6i4/VlBuHfuFK9MSX6inm6O9luKVK0vloQrHdZZHC+U dS+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tACN+7jJ+Kh2Tf2eJTxhD3lvs/6wWhho7rjnAyWr7Rs=; b=CXCSZo6I43MVhlyMs5DLkjfCHTakduJiPGSkw7siclsR0Q5GT1n5xy7RRZ7UKKagrd 1I/MYFeVI41Qt+tIZFCaw4+nCGAGrbIEt7GvDwYyMRBxjRHfKblkrWQVwggFxShDG0kI oRDhGbh/7xcSNrxSscsCEW+If+YGYkvSZ1GqLRTnX8U5sNApCJlj1FkxMUmu1aT3aqbl 8ILHCEypJqTgLzyM3E1apo5qtoGkZ1m51+vA4sZtNynSgJHjonEJOnTtsArwV1DJQMPa +qJzCSjA9onDiOb1Qqcx2pa5HnYNfovDnZTnwwkDnPhN1hS8o9YEWxGhs9goYbf/cd0c TCmQ==
X-Gm-Message-State: AJaThX6AS1Cmh+ceaygRDXjEv8WMtiszH6JFGGZX4igi59i9DKcAeWoE Ky+DZpg5FI0sZqPnEB7eZRI=
X-Google-Smtp-Source: AGs4zMYHpZWmV3oGkFhngl0a6ROTPbG+JZ/9UkwnlNqij/wegZwwpbSZac1hHAa96Crx6TTvpwZlHg==
X-Received: by 10.98.57.131 with SMTP id u3mr21113803pfj.7.1511402532998; Wed, 22 Nov 2017 18:02:12 -0800 (PST)
Received: from [10.242.118.183] ([73.109.61.71]) by smtp.gmail.com with ESMTPSA id r86sm25368622pfk.114.2017.11.22.18.02.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 18:02:11 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-3035F75B-4974-4579-B869-D0FA846C82E8
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (15B202)
In-Reply-To: <584cf317-ad5e-3261-ba88-8409610899d7@omnitor.se>
Date: Wed, 22 Nov 2017 18:02:09 -0800
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
Content-Transfer-Encoding: 7bit
Message-Id: <4391A04B-519E-4E3F-ACB8-1695D7B7B0F2@gmail.com>
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se>   <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>  <2DF564B4-88CD-4758-8F84-39BFCBD72B0E@gmail.com> <584cf317-ad5e-3261-ba88-8409610899d7@omnitor.se>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 23 Nov 2017 02:02:15 -0000

--Apple-Mail-3035F75B-4974-4579-B869-D0FA846C82E8
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Nov 22, 2017, at 3:47 PM, Gunnar Hellstr=C3=B6m  wrote:
>>=20
> Yes, I agree completely that speech recognition is a reality for real-=
time captioning today. But do you know implementations that transmit it as p=
art of a video media stream? What coding?

Here is an example that used machine learning to provide realtime captions i=
n multiple languages:
https://azure.microsoft.com/en-us/blog/live-real-time-captions-with-azure-me=
dia-services-and-player/?cdn=3Ddisable



--Apple-Mail-3035F75B-4974-4579-B869-D0FA846C82E8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Nov 22, 2017, at 3:47 PM=
, Gunnar Hellstr=C3=B6m <g=
unnar.hellstrom@omnitor.se> wrote:

<GH>Yes, I agree completely that speech recognition is a r=
eality for real-time captioning today. But do you know implementations that t=
ransmit it as part of a video media stream? What coding?

Here is an example that used machine learning to provide realtime captions=
 in multiple languages:


=

--Apple-Mail-3035F75B-4974-4579-B869-D0FA846C82E8--


From nobody Thu Nov 23 03:23:42 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 D378B128959 for ; Thu, 23 Nov 2017 03:23:40 -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 RNOvFv1q94am for ; Thu, 23 Nov 2017 03:23:39 -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 A3A62126CE8 for ; Thu, 23 Nov 2017 03:23:38 -0800 (PST)
X-Halon-ID: b7205403-d040-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id b7205403-d040-11e7-96ae-005056917f90; Thu, 23 Nov 2017 12:23:23 +0100 (CET)
To: Bernard Aboba 
Cc: slim@ietf.org, Randall Gellens , Paul Kyzivat , Brian Rosen 
References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>  <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net>    <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se>     <2b229df4-faef-65a0-e4ed-8b44a9f2e6a4@omnitor.se> <3F911C22-CF96-402C-AF4F-22CD761DFD5C@gmail.com>  <2DF564B4-88CD-4758-8F84-39BFCBD72B0E@gmail.com> <584cf317-ad5e-3261-ba88-8409610899d7@omnitor.se> <4391A04B-519E-4E3F-ACB8-1695D7B7B0F2@gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: 
Date: Thu, 23 Nov 2017 12:23:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4391A04B-519E-4E3F-ACB8-1695D7B7B0F2@gmail.com>
Content-Type: multipart/alternative; boundary="------------BDD63C5FABCE8A350F7FB8F0"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Proposed 5.4 text
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, 23 Nov 2017 11:23:41 -0000

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

Den 2017-11-23 kl. 03:02, skrev Bernard Aboba:
> On Nov 22, 2017, at 3:47 PM, Gunnar Hellström 
> > wrote:
>>
>> Yes, I agree completely that speech recognition is a reality for 
>> real-time captioning today. But do you know implementations that 
>> transmit it as part of a video media stream? What coding?
>
> Here is an example that used machine learning to provide realtime 
> captions in multiple languages:
> https://azure.microsoft.com/en-us/blog/live-real-time-captions-with-azure-media-services-and-player/?cdn=disable

Yes, a nice example.  Even if it is not from our application area - 
conversational calls, and not initiated by SDP, and not using a video 
media stream, but a multiplexed RTMP TCP based message stream with 
interleaved video chunks and text chunks, it is an example that reminds 
us that something similar could be set up in a conversational call with 
SDP and using video media with MPEG4 according to RFC 3640, 4337 or 6381.

That indicates to us that we have cases that are even less supported by 
our current draft. The video/mp4 media can contain video and audio and 
text. If that is used for a conversational call, we would need to 
collect 'hlang' attributes for all three modalities in the video media 
description, and possibly get them all agreed, and that is against one 
of our basic statements in section 3:

    (Negotiating multiple simultaneous languages within a media stream is
    out of scope of this document.)

So, ok, let us for now assume that we limit the application to 
traditional conversational calls with one media and language per stream 
and no multiplexing.

Gunnar

>
>
>
> _______________________________________________
> 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


--------------BDD63C5FABCE8A350F7FB8F0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Den 2017-11-23 kl. 03:02, skrev Bernard Aboba:

    

      
      
On Nov 22, 2017, at 3:47 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se>
        wrote:

      

        


          <GH>Yes, I agree completely that speech
            recognition is a reality for real-time captioning today. But
            do you know implementations that transmit it as part of a
            video media stream? What coding?
          

        

      

      


      

      
Here is an example that used machine learning to provide
        realtime captions in multiple languages:

      
    

    

    <GH>Yes, a nice example.  Even if it is not from our
    application area - conversational calls, and not initiated by SDP,
    and not using a video media stream, but a multiplexed RTMP TCP based
    message stream with interleaved video chunks and text chunks, it is
    an example that reminds us that something similar could be set up in
    a conversational call with SDP and using video media with MPEG4
    according to RFC 3640, 4337 or 6381.  

    

    That indicates to us that we have cases that are even less supported
    by our current draft. The video/mp4 media can contain video and
    audio and text. If that is used for a conversational call, we would
    need to collect 'hlang' attributes for all three modalities in the
    video media description, and possibly get them all agreed, and that
    is against one of our basic statements in section 3: 

    
   (Negotiating multiple simultaneous languages within a media stream is
   out of scope of this document.)



    So, ok, let us for now assume that we limit the application to
    traditional conversational calls with one media and language per
    stream and no multiplexing.

    

    Gunnar

    

    

      


      

      

      

      

      
_______________________________________________
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

  


--------------BDD63C5FABCE8A350F7FB8F0--


From nobody Thu Nov 23 14:04:39 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 11B28126CC7 for ; Thu, 23 Nov 2017 14:04:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 XpvEl6Wq7InD for ; Thu, 23 Nov 2017 14:04:35 -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 9A508120727 for ; Thu, 23 Nov 2017 14:04:34 -0800 (PST)
X-Halon-ID: 3ecf21ba-d09a-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 3ecf21ba-d09a-11e7-96ae-005056917f90; Thu, 23 Nov 2017 23:04:17 +0100 (CET)
To: Bernard Aboba , slim@ietf.org
References: 
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= 
Message-ID: <848cc7ab-0145-9492-5cdf-265550753967@omnitor.se>
Date: Thu, 23 Nov 2017 23:04:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2B18665E6CEFE0C97E0CD8C2"
Content-Language: en-US
Archived-At: 
Subject: Re: [Slim] Announcement of SLIM WG Last Call on draft-ietf-slim-negotiating-human-language-18
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, 23 Nov 2017 22:04:38 -0000

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

I have reviewed the draft and find it acceptable.

I found a small editorial error, and have a proposal for another 
editorial change.

--First change---------Section 6.1, 8th line -----------------

-------Old text--------------------------------------
     hlang-value =  Language-Tag *( SP Language-tag )
------New text----------------------------------------
     hlang-value =  Language-Tag *( SP Language-Tag )
-----------------------------------------------^-----

------End of first change-----------------------------------------
------Second change-------------------------------
I suggest to add Addison Phillips to the acknowledgement chapter 11.
------End of change proposals-------------------

Regards

Gunnar

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





Den 2017-11-22 kl. 08:28, skrev Bernard Aboba:
> This is an announcement of SLIM WG Last Call on 
> draft-ietf-slim-negotiating-human-language-18.  The draft is available 
> for inspection here:
> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-18
>
> Since this document has already been through a WG last call as well as 
> an IETF last call and considerable WG discussion, this final WG last 
> call will last for a week.
>
> Please post your last comments to the SLIM WG mailing list by November 
> 30, 2017.
>
> The SLIM WG also requests that participants disclose IPR relating to 
> draft-ietf-slim-negotiating-human-language-18 by November 30, 2017.
>
>
> _______________________________________________
> 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


--------------2B18665E6CEFE0C97E0CD8C2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I have reviewed the draft and find it acceptable. 

    

    
I found a small editorial error, and have a proposal for another
      editorial change. 

    

    
--First change---------Section 6.1, 8th line -----------------

    
-------Old text--------------------------------------
    hlang-value =  Language-Tag *( SP Language-tag )
------New text----------------------------------------
    hlang-value =  Language-Tag *( SP Language-Tag )
-----------------------------------------------^-----


    ------End of first change-----------------------------------------

    ------Second change-------------------------------

    I suggest to add Addison Phillips to the acknowledgement chapter 11.

    ------End of change proposals-------------------

    

    Regards

    

    Gunnar

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

    

    

    

    

    
Den 2017-11-22 kl. 08:28, skrev Bernard
      Aboba:

    

    

      
This is an announcement of SLIM WG Last Call on
        draft-ietf-slim-negotiating-human-language-18.  The draft is
        available for inspection here: 
        
        


        

        
Since this document has already been through a WG last call
          as well as an IETF last call and considerable WG discussion,
          this final WG last call will last for a week. 

        


        

        
Please post your last comments to the SLIM WG mailing list
          by November 30, 2017. 

        


        

        
The SLIM WG also requests that participants disclose IPR
          relating to draft-ietf-slim-negotiating-human-language-18 by
          November 30, 2017. 

      

      

      

      

      
_______________________________________________
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

  


--------------2B18665E6CEFE0C97E0CD8C2--


From nobody Mon Nov 27 19:45:16 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 46E7B129415 for ; Mon, 27 Nov 2017 19:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 OFYRIMtowr5e for ; Mon, 27 Nov 2017 19:45:13 -0800 (PST)
Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 AC42E1201F2 for ; Mon, 27 Nov 2017 19:45:13 -0800 (PST)
Received: by mail-vk0-x242.google.com with SMTP id 22so18877880vkq.4 for ; Mon, 27 Nov 2017 19:45:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=nkge/BnjDdHYnVlYoVyPJoGsVnc2aQCIOQwe5FeuUPs=; b=YcPK3UH4yUZUNT1hbfnSchyAVgdE+/Z/3U9QBmLEI6eq7el4QYY4HDsHTLcF34IlFt 8DOZzUHZXiZQhV1uw7AIm7Fwcr7QpGWtYvmMN0LzoNUadIbpf8fXYw6bPYh7FyXKuY15 kToif7xvmnw6LsJu5Y5ej2Ms3l/xbeGAWHfM9ZkkHBm+wlZJ0nJ7M2E2A7sa9VjqNLXO m9uBn3M0P5Nzd+o7ahiXkKoqloiXtw8fUp5g8m7PLDTLm/BhL3v68yn8s0ytyxMHUvLd XqpThrwcsVEcfCmP4vaQQMmJKtj9TB1ny81S4NidrrE2IXI4ubHmhj4oQpldXs+6cwWK KEdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nkge/BnjDdHYnVlYoVyPJoGsVnc2aQCIOQwe5FeuUPs=; b=ZlbOfLzyUVThk1X31uGHi3jmLn/Fg7U1wWeXRfmAmnJLQVibh7BHcBaVUlAMTsOqqJ Z3xNkhrITWImL5aGH4z8vbUlzSxv9hcMhPX/8tH1YTz62GstcU3ERXrMxfrd5XM/6hsP eyQMNLWGkCd1VWadgStItRZ8LVrg71+MQPzMH4aLJbcel5I9dvdix/sHpIFAGMWMFwUS 4kzzefQtghfIcgfNNd7D/2Oz1Rw5htxQ8CtSGhYEQNOqX0fUQexxiOSk15dh0oBiIHjg 8jFeWQI+G6i8hus/B0M4qmOrebKP0RqtOZSyzPkgK5osroHdrcLiW7hBDP7IAYNDSrEJ ekzw==
X-Gm-Message-State: AJaThX7PimsYfz3QXuvUu/M6O3ipkyPXkI+w/v80E+3YLNNBYYTD7gSl LOfhNGmEHSF1rUJ7XSWtEQFdM7LGf1WuFigONnef3YmB
X-Google-Smtp-Source: AGs4zMa/OistfMEpF1FxQUt2smHoqYOxOAG+hYNzUAtBR0TcDzsgZ7kADZL8czNKDVMAqo+i6kjDe0xY98T0IHnolr8=
X-Received: by 10.31.163.10 with SMTP id m10mr18977011vke.85.1511840712495; Mon, 27 Nov 2017 19:45:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Mon, 27 Nov 2017 19:44:52 -0800 (PST)
From: Bernard Aboba 
Date: Mon, 27 Nov 2017 19:44:52 -0800
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a1142e8c6a017f6055f02d887"
Archived-At: 
Subject: [Slim] REMINDER: WG last call on draft-ietf-slim-negotiating-human-language-18
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 Nov 2017 03:45:15 -0000

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

This is a reminder that there is an ongoing WG last call on
draft-ietf-slim-negotiating-human-language-18, as well as a call for IPR
declarations, both concluding on November 30, 2017.

The draft is available for inspection here:

https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-18


So far two editorial comments have been received:
Gunnar:
https://mailarchive.ietf.org/arch/msg/slim/PVgPYGK68MA01Hf9RUclVdXyF3g
Keith:
https://mailarchive.ietf.org/arch/msg/slim/DdzQHdN3LaGgs6JKZqny3YNVn4w

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


This is a reminder that there is an ongoing WG last call o=
n draft-ietf-slim-negotiating-human-language-18, as well as a call for IPR =
declarations, both concluding on November 30, 2017.=C2=A0

The draft is available for inspection here:=C2=A0

So far two editorial comme=
nts have been received:=C2=A0


--001a1142e8c6a017f6055f02d887--


From nobody Tue Nov 28 05:18: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 926F312711E for ; Tue, 28 Nov 2017 05:18:27 -0800 (PST)
X-Quarantine-ID: <80_1L6SCDQbs>
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] 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 80_1L6SCDQbs for ; Tue, 28 Nov 2017 05:18:14 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9D124B18 for ; Tue, 28 Nov 2017 05:18:14 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 28 Nov 2017 05:18:24 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <848cc7ab-0145-9492-5cdf-265550753967@omnitor.se>
References:  <848cc7ab-0145-9492-5cdf-265550753967@omnitor.se>
X-Mailer: Eudora for Mac OS X
Date: Tue, 28 Nov 2017 05:14:54 -0800
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?=  , Bernard Aboba , slim@ietf.org
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Slim] Announcement of SLIM WG Last Call on draft-ietf-slim-negotiating-human-language-18
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 Nov 2017 13:18:27 -0000

At 11:04 PM +0100 11/23/17, Gunnar Hellstr=F6m wrote:

>  I have reviewed the draft and find it acceptable.
>
>  I found a small editorial error, and have a=20
> proposal for another editorial change.
>
>  --First change---------Section 6.1, 8th line -----------------
>
>  -------Old text--------------------------------------
>      hlang-value =3D  Language-Tag *( SP Language-tag )
>  ------New text----------------------------------------
>      hlang-value =3D  Language-Tag *( SP Language-Tag )
>  -----------------------------------------------^-----
>   ------End of first change-----------------------------------------

Thanks for spotting this.


>  ------Second change-------------------------------
>  I suggest to add Addison Phillips to the acknowledgement chapter 11.
>  ------End of change proposals-------------------

Agreed, thank you.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Walter Benjamin's concept of "aura" in simple terms means that
something assumes a particularly intense and melancholy power
to fascinate at the moment of its disappearance.
                --Joachim Kalka, from "Money As We Knew It."


From nobody Thu Nov 30 16:10: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 8E20112704B for ; Thu, 30 Nov 2017 16:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mtox2aOllpG0 for ; Thu, 30 Nov 2017 16:10:47 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 F24BB1270A7 for ; Thu, 30 Nov 2017 16:10:46 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id i4so6944241uab.5 for ; Thu, 30 Nov 2017 16:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=bOyaOZIo4MvICsE3LKn4PmXNQAhbdP7jgsFlHu9/RIE=; b=QWWWB0irYMGgaB5DfAuxiFPifn1IpN4BeagdnC31Q0Q5Su0RWk+OjV5rCD5eRJ8G8Q qUrC/mOtMxByLX8XkIi1c1F9Ru50eb2ITCLOVu3dJKs4SYernS+E9oIn6BCX7OzHHKXC cGh/rDcRKraI/qdn7tqhxjGlfD5+Dvut5iDLnfLkZNzD1/Uc0h+Jm19hAGQbgeIxSUra cSsQTR5cPTUVFSKV2c5UBJ5ynsE+QdPv0HunpNPq8Q8GTx6dKf1GwPfwtZqf+v3pYP8x QzrOy3yqyJhg3hCiN/PppC519MiN+WPA+hBkkpK3DpxQhR0+iCSx1FvtoC4pgGw/9uyd t82g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bOyaOZIo4MvICsE3LKn4PmXNQAhbdP7jgsFlHu9/RIE=; b=MeylaN8It7DDqKhRMNaPWvkYKHu+DG4w2jgjr+3+N8511kfEwD2SbvR269AwfLX5lr rtcp1mFoY/qPHNWk2biHfE0KOLbwjzpLybE3NlVYVqevSUvLz6oBStFTPy1pQ2jN18K8 +Ic0RQmT0ELj1HlXs9MCzmd67S/snd0tTyZOVLwGmrbnY3YXkZaVYN3U3NgWfcV746P1 HONBBoTTJ9fSdeAB32gDdXIf+SOT3hf3lwJpGpec+4lDgUALZw25JzxpgZmsBC0oUcKQ zFr7aKpKB0h7IHsksNFmCo7jPt1W0jptZ6JkkGFm0wFlHCbVzGycMZ9D15ckcpeh6W+A hs/A==
X-Gm-Message-State: AJaThX52hIglhHT7DMhbz4RoeS+vA3IaG4MXoiBijR1Y/NBEU7H47xrf u4b7zUoLRF0OrluygALc2APWtvvQhNh1aohzYqSr/gg4
X-Google-Smtp-Source: AGs4zMb1W+ZK8wfkkK3rnjrME5zCY/EpwCIqp2z109BGLQDMLZznTI8YqfpDLqrU6smnD4EjWE6vZlzLJ4gLNeH3NYg=
X-Received: by 10.176.2.116 with SMTP id 107mr3279509uas.8.1512087045745; Thu, 30 Nov 2017 16:10:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.1.180 with HTTP; Thu, 30 Nov 2017 16:10:24 -0800 (PST)
From: Bernard Aboba 
Date: Thu, 30 Nov 2017 16:10:24 -0800
Message-ID: 
To: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a113e45d43b3164055f3c33c0"
Archived-At: 
Subject: [Slim] Conclusion of WG last call on draft-ietf-slim-negotiating-human-language-18
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: Fri, 01 Dec 2017 00:10:48 -0000

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

SLIM WG last call on draft-ietf-slim-negotiating-human-language-18 has
concluded.


Two editorial comments were received:
Gunnar: https://mailarchive.ietf.org/arch/msg/slim/
PVgPYGK68MA01Hf9RUclVdXyF3g
Keith: https://mailarchive.ietf.org/arch/msg/slim/
DdzQHdN3LaGgs6JKZqny3YNVn4w

Randall - can you address the editorial comments in a -19, so we can
request publication?

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


SLIM WG last call on draft-ietf-slim-negotiating-human-lan=
guage-18 has concluded.=C2=A0


Randall - can you address the editorial comments in a -19, so we=
 can request publication?


--001a113e45d43b3164055f3c33c0--


From nobody Thu Nov 30 21:11:32 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 B5C2C1250B8 for ; Thu, 30 Nov 2017 21:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 em-9mxgoXPwn for ; Thu, 30 Nov 2017 21:11:29 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 676EC1201F8 for ; Thu, 30 Nov 2017 21:11:29 -0800 (PST)
Received: from [100.98.229.244] (127.0.0.1) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 30 Nov 2017 21:11:40 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-C999E78C-CC13-4B8F-99DD-708B78B9F052
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Randall Gellens 
In-Reply-To: 
Date: Thu, 30 Nov 2017 21:34:37 -0500
Cc: slim@ietf.org
Message-Id: 
References: 
To: Bernard Aboba 
X-Mailer: iPhone Mail (14G60)
Archived-At: 
Subject: Re: [Slim] Conclusion of WG last call on draft-ietf-slim-negotiating-human-language-18
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: Fri, 01 Dec 2017 05:11:31 -0000

--Apple-Mail-C999E78C-CC13-4B8F-99DD-708B78B9F052
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

-19 is ready to go. I'll upload it when I'm back with my laptop, Friday.=20

--Randy

Sent from my iPhone

> On Nov 30, 2017, at 7:10 PM, Bernard Aboba  wrote=
:
>=20
> SLIM WG last call on draft-ietf-slim-negotiating-human-language-18 has con=
cluded.=20
>=20
>=20
> Two editorial comments were received:=20
> Gunnar: https://mailarchive.ietf.org/arch/msg/slim/PVgPYGK68MA01Hf9RUclVdX=
yF3g
> Keith: https://mailarchive.ietf.org/arch/msg/slim/DdzQHdN3LaGgs6JKZqny3YNV=
n4w
>=20
> Randall - can you address the editorial comments in a -19, so we can reque=
st publication?
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>=20

--Apple-Mail-C999E78C-CC13-4B8F-99DD-708B78B9F052
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


-19 is ready to go. I'll upload it whe=
n I'm back with my laptop, Friday. 

--Randy

Sent from my iPhone=


On Nov 30, 2017, at 7:10 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

<=
/div>
SLIM WG last call on dr=
aft-ietf-slim-negotiating-human-language-18 has concluded. 


Randall - can you address the editorial com=
ments in a -19, so we can request publication?



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

=

--Apple-Mail-C999E78C-CC13-4B8F-99DD-708B78B9F052--