From nobody Thu Oct 1 12:03:23 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035061A8874; Thu, 1 Oct 2015 12:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ctM6ChMhXdo; Thu, 1 Oct 2015 12:03:19 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 2215D1A8871; Thu, 1 Oct 2015 12:03:19 -0700 (PDT) Received: by iow1 with SMTP id 1so59304358iow.1; Thu, 01 Oct 2015 12:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FH/kpkFpZdz34e7762tsKpqJH6aYhSuRqVX9wzpMgq4=; b=BpOrX37UoPuVYPNav5LK4NEAuc0yC4lujc+K02/0IixCTwNRtrcN3lWB3oSzs7Xvgt kbNGEfBf8hGF/96ESqfGj4L8u4V3d6bNzIGHEc0qlBcRxEXStolGQljNvGoawlkhDEXv JnvxAaF1XW6TrNlL0sDnA3qI844qu+xqCX1UuxCNLYLHmb/xXyM63x9SHJcof3dJrDFB zR0PRJqgWaJvB5oSz9box2c+Gidbfp6PZG/aUoQwTaMGo1cNyXS8c6W36uiZm+QN9WbR 2i0y0roC80wRa+dxY4UPFJf1FDu9zwWusVqN3/LRgBTVQJ/k8eorgeZuK3Hu7Z8WAX10 /ynA== MIME-Version: 1.0 X-Received: by 10.107.11.154 with SMTP id 26mr14538329iol.105.1443726198481; Thu, 01 Oct 2015 12:03:18 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.17.24 with HTTP; Thu, 1 Oct 2015 12:03:18 -0700 (PDT) In-Reply-To: <560C1436.6080200@omnitor.se> References: <560988C3.6080402@omnitor.se> <5609BBA6.9080101@cs.tcd.ie> <560AAFB2.4060805@cs.tcd.ie> <560AFD5A.5060101@cs.tcd.ie> <560B8CC1.2060405@cs.tcd.ie> <560C0716.8050404@alum.mit.edu> <476BCA21-7802-4E39-A22A-835BE66E15E8@brianrosen.net> <560C1019.80509@alum.mit.edu> <560C1436.6080200@omnitor.se> Date: Thu, 1 Oct 2015 15:03:18 -0400 X-Google-Sender-Auth: Z9RmXak-F13LC0P_4RcNMcq8OwE Message-ID: From: Barry Leiba To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= , Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 19:03:20 -0000 (It doesn't help that Stephen got removed from the CC list on this part of the thread, and it might be best to put the IESG back onto it also; I'm doing both here.) > Is there anyone against the view that this discussion can take place when > composing the security chapters, and does not influence the charter? > > The discussion is good, and material can be collected for the security > chapters. Thanks, Gunnar; this is where my mind is on the point. Stephen, though, seems to have a position that this work shouldn't proceed until a broader analysis is done. I'm very much not convinced of that, and I'd like more from Stephen on that point. I think everyone agrees that whatever documents are produced by this working group have to consider the privacy issues raised by language labelling. I don't think we need that explicitly called out in the charter ("The working group must eat its vegetables."), but I'm happy to have text in there if there's some specific text proposed. What I think is not agreed upon is whether this work needs to be gated on an overall privacy analysis of adding information (in general) to SIP calls. Let's please continue the discussion on that *with* Stephen and the IESG in the loop. Barry From nobody Fri Oct 2 00:35:35 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2821ACE39; Fri, 2 Oct 2015 00:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kOceyxARpDq; Fri, 2 Oct 2015 00:35:31 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 DCB921ACE36; Fri, 2 Oct 2015 00:35:30 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so21553143wic.0; Fri, 02 Oct 2015 00:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pp5en5/AlgGZ+I0qgpAoHgo6NjQyYFIxOjGpzvVoSeM=; b=vrw8qh5CXEBKyc4mm8iRm/LFZ6DTci8YFaKduYqwNfDBGKcgw++q8tSaEIUlB+QjTY fJIEXnzq9h5mXsYwAOdumIpStjWJJz9ZjnVR5yA/82vvQHOJpNFq3gcAoQ+l9s2Io7n+ dzXV2V8pM2UKTxbaV4heg8V/KY3iGYCZw7e2YIDe655hMsergdvfQgZUkcgrJvXKraMd FbZ4Wbz9h+u0prYmAPtS050GFKFlqVaAPmoTeuGxzy+6KVpHgkORcGe4JuPgWz3cSTNs uBIGqf0zf2g4ctfMfmLJeUQqjT3xeseMT6Ve6+kmSosrbvt29SeM0y1lKBVr+qzzlMjk ZniQ== X-Received: by 10.180.187.180 with SMTP id ft20mr2816977wic.78.1443771329500; Fri, 02 Oct 2015 00:35:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.13.106 with HTTP; Fri, 2 Oct 2015 00:35:09 -0700 (PDT) In-Reply-To: References: <560988C3.6080402@omnitor.se> <5609BBA6.9080101@cs.tcd.ie> <560AAFB2.4060805@cs.tcd.ie> <560AFD5A.5060101@cs.tcd.ie> <560B8CC1.2060405@cs.tcd.ie> <560C0716.8050404@alum.mit.edu> <476BCA21-7802-4E39-A22A-835BE66E15E8@brianrosen.net> <560C1019.80509@alum.mit.edu> <560C1436.6080200@omnitor.se> From: Bernard Aboba Date: Fri, 2 Oct 2015 00:35:09 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c33e843b5f3505211a3546 Archived-At: Cc: slim@ietf.org, =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= , IESG , Stephen Farrell Subject: Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 07:35:34 -0000 --001a11c33e843b5f3505211a3546 Content-Type: text/plain; charset=UTF-8 Barry said: "What I think is not agreed upon is whether this work needs to be gated on an overall privacy analysis of adding information (in general) to SIP calls." [BA] Brian Rosen has made the point that (at a high level) we already know what that security/privacy analysis is going to say, because including language information in SDP or SIP headers does not change the fundamental security properties of SIP. So gating the work on that analysis is like hoping that your next viewing of The Shining will have a more pleasant ending. The security facilities of SIP are well understood and their properties have been analyzed before. We have SIP over TLS, which is hbh, (undeployed) S/MIME, which can protect message bodies e2e, and RFC 4474bis. We also more or less understand what a privacy analysis would say: if the user wants to provide information to enable better routing of their call (e.g. language preference), this information cannot be kept secret from the proxies that do the routing. On Thu, Oct 1, 2015 at 12:03 PM, Barry Leiba wrote: > (It doesn't help that Stephen got removed from the CC list on this > part of the thread, and it might be best to put the IESG back onto it > also; I'm doing both here.) > > > Is there anyone against the view that this discussion can take place when > > composing the security chapters, and does not influence the charter? > > > > The discussion is good, and material can be collected for the security > > chapters. > > Thanks, Gunnar; this is where my mind is on the point. Stephen, > though, seems to have a position that this work shouldn't proceed > until a broader analysis is done. I'm very much not convinced of > that, and I'd like more from Stephen on that point. > > I think everyone agrees that whatever documents are produced by this > working group have to consider the privacy issues raised by language > labelling. I don't think we need that explicitly called out in the > charter ("The working group must eat its vegetables."), but I'm happy > to have text in there if there's some specific text proposed. > > What I think is not agreed upon is whether this work needs to be gated > on an overall privacy analysis of adding information (in general) to > SIP calls. > > Let's please continue the discussion on that *with* Stephen and the > IESG in the loop. > > Barry > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --001a11c33e843b5f3505211a3546 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry said:=C2=A0

"What I think is n= ot agreed upon is whether this work needs to be gated
on an overall privacy anal= ysis of adding information (in general) to
SIP calls."
[BA] Brian Rosen has made the point that (at a high level) we a= lready know what that security/privacy analysis is going to say, because in= cluding language information in SDP or SIP headers does not change the fund= amental security properties of SIP.=C2=A0 So gating the work on that analys= is is like hoping that your next viewing of The Shining will have a more pl= easant ending. =C2=A0

The security facilities of S= IP are well understood and their properties have been analyzed before.=C2= =A0 We have SIP over TLS, which is hbh, =C2=A0(undeployed) S/MIME, which ca= n protect message bodies e2e, and RFC 4474bis. =C2=A0

<= div>We also more or less understand what a privacy analysis would say: =C2= =A0if the user wants to provide information to enable better routing of the= ir call (e.g. language preference), this information cannot be kept secret = from the proxies that do the routing. =C2=A0



On Thu, Oct 1, 2015 at 12:03 PM, Barry Leiba &l= t;barryleiba@c= omputer.org> wrote:
(It doe= sn't help that Stephen got removed from the CC list on this
part of the thread, and it might be best to put the IESG back onto it
also; I'm doing both here.)

> Is there anyone against the view that this discussion can take place w= hen
> composing the security chapters, and does not influence the charter? >
> The discussion is good, and material can be collected for the security=
> chapters.

Thanks, Gunnar; this is where my mind is on the point.=C2=A0 Stephen= ,
though, seems to have a position that this work shouldn't proceed
until a broader analysis is done.=C2=A0 I'm very much not convinced of<= br> that, and I'd like more from Stephen on that point.

I think everyone agrees that whatever documents are produced by this
working group have to consider the privacy issues raised by language
labelling.=C2=A0 I don't think we need that explicitly called out in th= e
charter ("The working group must eat its vegetables."), but I'= ;m happy
to have text in there if there's some specific text proposed.

What I think is not agreed upon is whether this work needs to be gated
on an overall privacy analysis of adding information (in general) to
SIP calls.

Let's please continue the discussion on that *with* Stephen and the
IESG in the loop.

Barry

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

--001a11c33e843b5f3505211a3546-- From nobody Fri Oct 2 01:46:32 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7B61ACEC3; Fri, 2 Oct 2015 01:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPyH0mhLy9lY; Fri, 2 Oct 2015 01:46:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACF31ACEC2; Fri, 2 Oct 2015 01:46:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D782CBDF9; Fri, 2 Oct 2015 09:46:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g25mH9ZLXxXY; Fri, 2 Oct 2015 09:46:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.22.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1DACBDD0; Fri, 2 Oct 2015 09:46:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1443775585; bh=028VZjS3HLxU74iTXsSSbZIai93oIblaxWZ8XfIvkx8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YTjP3r9CN0pfXzsQcI72sOxK/eJNhQ2dQ7OIuiND1Ot3x0dh2I7aSqEKl0aNcQiCO UwAqVRqGqk/btlU5ZnNuxP61P4bMjhh/XS0GUwfzlUo/KBoCPdUYyd44qItxbfbMCR umncULjoT1m3dkKU3V5j6gyo5LmXbc+ZLiO4X6xY= To: Barry Leiba , =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= References: <560988C3.6080402@omnitor.se> <5609BBA6.9080101@cs.tcd.ie> <560AAFB2.4060805@cs.tcd.ie> <560AFD5A.5060101@cs.tcd.ie> <560B8CC1.2060405@cs.tcd.ie> <560C0716.8050404@alum.mit.edu> <476BCA21-7802-4E39-A22A-835BE66E15E8@brianrosen.net> <560C1019.80509@alum.mit.edu> <560C1436.6080200@omnitor.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <560E4460.4030407@cs.tcd.ie> Date: Fri, 2 Oct 2015 09:46:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 08:46:31 -0000 Hiya, On 01/10/15 20:03, Barry Leiba wrote: > I think everyone agrees that whatever documents are produced by this > working group have to consider the privacy issues raised by language > labelling. I don't think we need that explicitly called out in the > charter ("The working group must eat its vegetables."), but I'm happy > to have text in there if there's some specific text proposed. I'm asking that the analysis be somewhat broader than only considering language. (On the basis that if we define how to add language then other personal attributes are likely to be similarly handled in the relevant protocols, UAs and servers.) If one did agree with that then I do think it ought be included in the charter. > > What I think is not agreed upon is whether this work needs to be gated > on an overall privacy analysis of adding information (in general) to > SIP calls. Right, I get that the gating thing is iccky, and Bernard rightly points out that even when we try do all that well, the end results might not be so great, which is a totally fair point. How about something like this: "It is not unlikely that once there is a method for using language as planned here, some implementations may similarly handle other personal attributes. The wg will analyse the security and privacy issues arising from having UAs emit language or other similar attributes and then handle language attributes accordingly." Not great wording, but I hope I'm getting clearer;-) S. From nobody Sat Oct 3 03:05:43 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF9D1ACEB1 for ; Sat, 3 Oct 2015 03:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK2-3dTGqW6c for ; Sat, 3 Oct 2015 03:05:40 -0700 (PDT) Received: from bin-vsp-out-05.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 B2C2C1ACEB0 for ; Sat, 3 Oct 2015 03:05:39 -0700 (PDT) X-Halon-ID: 4ae518a9-69b6-11e5-b53c-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 3 Oct 2015 12:05:36 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <560FA86D.8080201@omnitor.se> Date: Sat, 3 Oct 2015 12:05:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 10:05:42 -0000 The limitations of having the language indications in SDP is eternally popping up as a problem when planning its use. I know that this has been discussed a lot in the past and that we have agreed to go the SDP path. But I want to question it again. I got a reminder from reviewing the latest specification of real-time text in WebRTC. https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02 There, the real-time text stream is a subchannel multiplexed in the WebRTC data channel, with sdp-specification m=application. So, there is no m=text to hook our humintlang attributes on. It is quite likely that WebRTC terminals will be used in situations where language negotiation is desirable. If we keep it under SDP, we would then need to define some mapping rules between languages for media not appearing under their original m= names. A tempting alternative is to move the whole language indication to an XML block carried in a defined place, so that it can be reused in different environments. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Oct 3 11:42:49 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344591A0636 for ; Sat, 3 Oct 2015 11:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7I-XR6KW73b for ; Sat, 3 Oct 2015 11:42:46 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1901A0469 for ; Sat, 3 Oct 2015 11:42:43 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-03v.sys.comcast.net with comcast id Qiii1r0022PT3Qt01iiibR; Sat, 03 Oct 2015 18:42:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id Qiii1r0073Ge9ey01iiiHb; Sat, 03 Oct 2015 18:42:42 +0000 To: slim@ietf.org References: <560FA86D.8080201@omnitor.se> From: Paul Kyzivat Message-ID: <561021A1.4040408@alum.mit.edu> Date: Sat, 3 Oct 2015 14:42:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560FA86D.8080201@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1443897762; bh=0GzVJqEZA0ioArVKjl9JyUJ6vKjgB9f+OUlGzXbEeTk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bX7Sbmb9ouU/F79bMghc9w7gr+K/KurkdU5rHKErmPKBfbnSE9sEd5w0KlAbjfi/K shr+qYZqhyWKhVSqD/zFtx3VwsGXm8iwvHjJPNL8j2OI0B0KlsY4qylIntudUlxUxc eirIQzlFlzrRZic6PmbQfscm0TBKO0BOqXo09tzV4RBAsAbypeRvgb73nKS3Q9ntBj gDNChK8pQI4/UnoYVJSuTQLT9afLZyjtzaCg7wUhTgoG+rUGMSFNaUz+UQKDUG5aSY aKrTRzxkiCQJjwzQaDdlNiBfDkGXZyXqa/Ty9gdzVClQH1M0lxOjJ2IF80F7V93xpO bMXu4zbrVRPuw== Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 18:42:47 -0000 On 10/3/15 6:05 AM, Gunnar Hellström wrote: > The limitations of having the language indications in SDP is eternally > popping up as a problem when planning its use. > I know that this has been discussed a lot in the past and that we have > agreed to go the SDP path. > > But I want to question it again. > I got a reminder from reviewing the latest specification of real-time > text in WebRTC. > https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02 > > There, the real-time text stream is a subchannel multiplexed in the > WebRTC data channel, with sdp-specification m=application. > So, there is no m=text to hook our humintlang attributes on. > > It is quite likely that WebRTC terminals will be used in situations > where language negotiation is desirable. > If we keep it under SDP, we would then need to define some mapping rules > between languages for media not appearing under their original m= names. > A tempting alternative is to move the whole language indication to an > XML block carried in a defined place, so that it can be reused in > different environments. This is not a unique issue here. It seems likely that individual data channels over sctp will start to be used in a variety of places where UDP is currently used. See draft-ietf-mmusic-data-channel-sdpneg. In particular section 5.1.2. Thanks, Paul From nobody Sat Oct 3 20:37:08 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD461B31D4 for ; Sat, 3 Oct 2015 20:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ3_PIjrX0cm for ; Sat, 3 Oct 2015 20:37:05 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 C84B01B31D3 for ; Sat, 3 Oct 2015 20:37:05 -0700 (PDT) Received: by pacex6 with SMTP id ex6so142843485pac.0 for ; Sat, 03 Oct 2015 20:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=VExJIAXSG5/zLpuzPpvjeBWlX5CEYKpMPR6wzQKl1AI=; b=0cvndvq1WOH+rdH8H8qvZEC8GxFTVwmOzHTzH7/wbTQbkgZmvGkLm70+7rtkdtt2Ru DcJjk/2bS3MliXd7UDon4Gmt1SRpWBLxZE/RfD88pZ/Kx8C2txTMaScfLiObDW3sXN/3 OoPgxHRs3Di82QDgssR7bw18WZLRoz+rsTudUiLkL2+qfKCHqmxd2ezmM5e97BZEq2EW s5bD8vEU5EiixsCE2dmmgm3i/NoAOdfLipGSYhp/G8wbr7nJGtREYWKgMOt6x2/d2UI0 L7eemULII7sJhX0tyX3J3kWZ6BEKhJlN+i8FdfIfJtyF1UTLAyxWrdcHI5Nylwbus0fs /Dbw== X-Received: by 10.68.57.143 with SMTP id i15mr30859294pbq.104.1443929825323; Sat, 03 Oct 2015 20:37:05 -0700 (PDT) Received: from [192.168.1.149] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id g5sm20075515pat.21.2015.10.03.20.37.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 20:37:04 -0700 (PDT) From: Bernard Aboba Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <48F2AAB3-AD31-401F-92C7-572E49AD5819@gmail.com> Date: Sat, 3 Oct 2015 20:37:02 -0700 References: <560FA86D.8080201@omnitor.se> <561021A1.4040408@alum.mit.edu> In-Reply-To: <561021A1.4040408@alum.mit.edu> To: slim@ietf.org X-Mailer: iPad Mail (13A452) Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 03:37:07 -0000 >> I got a reminder from reviewing the latest specification of real-time >> text in WebRTC. >> https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-= 02 >>=20 >> There, the real-time text stream is a subchannel multiplexed in the >> WebRTC data channel, with sdp-specification m=3Dapplication. >> So, there is no m=3Dtext to hook our humintlang attributes on. >> It is quite likely that WebRTC terminals will be used in situations >> where language negotiation is desirable. [BA] If we are talking about a WEBRTC application talking over the data chan= nel to a gateway that translates to RTT, the gateway can compose the m=3Dtex= t line to hang the humintlang attributes on. The WEBRTC application need no= t speak SDP to the gateway to accomplish this, it just needs to provide the i= nformation the gateway needs to compose the m=3Dtext line and humintlang att= ributes. This could be in any desired format: JSON, XML, etc. >> If we keep it under SDP, we would then need to define some mapping rules >> between languages for media not appearing under their original m=3D names= . [BA] The gateway would need such a mapping, but it is not clear to me why th= is application-specific signaling would need to be standardized. =20= From nobody Sat Oct 3 23:47:33 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626521A9066 for ; Sat, 3 Oct 2015 23:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn9VY8A8tu3H for ; Sat, 3 Oct 2015 23:47:28 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCA41A9063 for ; Sat, 3 Oct 2015 23:47:27 -0700 (PDT) X-Halon-ID: c5cc3492-6a63-11e5-b53c-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 4 Oct 2015 08:47:25 +0200 (CEST) To: slim@ietf.org References: <560FA86D.8080201@omnitor.se> <561021A1.4040408@alum.mit.edu> <48F2AAB3-AD31-401F-92C7-572E49AD5819@gmail.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5610CB7A.3020705@omnitor.se> Date: Sun, 4 Oct 2015 08:47:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <48F2AAB3-AD31-401F-92C7-572E49AD5819@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 06:47:31 -0000 Den 2015-10-04 kl. 05:37, skrev Bernard Aboba: >>> I got a reminder from reviewing the latest specification of real-time >>> text in WebRTC. >>> https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02 >>> >>> There, the real-time text stream is a subchannel multiplexed in the >>> WebRTC data channel, with sdp-specification m=application. >>> So, there is no m=text to hook our humintlang attributes on. >>> It is quite likely that WebRTC terminals will be used in situations >>> where language negotiation is desirable. > [BA] If we are talking about a WEBRTC application talking over the data channel to a gateway that translates to RTT, the gateway can compose the m=text line to hang the humintlang attributes on. The WEBRTC application need not speak SDP to the gateway to accomplish this, it just needs to provide the information the gateway needs to compose the m=text line and humintlang attributes. This could be in any desired format: JSON, XML, etc. > >>> If we keep it under SDP, we would then need to define some mapping rules >>> between languages for media not appearing under their original m= names. > [BA] The gateway would need such a mapping, but it is not clear to me why this application-specific signaling would need to be standardized. [GH] It is the usual reasons to standardize. Development of different parts of a system can be distributed in time and between organizations. What is developed for one application can be reused in another. One part of a system can be based on one technology and another part on another technology. Application functions can be implemented relatively easily end - to - end even if the communicating partners have tools using different technologies. Application functions are of interest to the users, and can be discussed in general terms with the users and need not be limited by lack of specification for the function in one technology or between them. In line with this reasoning is also my hope that what we do to now can have as wide scope as possible without extra efforts. Many WebRTC applications are based on SIP and SDP. So we could hope that the work was directly applicable for these cases, but it is not because the current idea relies on consistent media names in m-lines. Other WebRTC applications use other methods, so you are right in that a language and modality indication in JSON or XML could have a wider scope than the one merged into the SDP media specifications. Even within traditional SIP and SDP, we have media specifications that can contain different media. E.g. MSRP using m=message with a possibility to convey messages with audio, video, images and text. And there is SIP MESSAGE transmission without any SDP. These are not really real-time communication, so I have accepted that our work does not have them in scope. Our scope on the real-time side of slim has so far been real-time text, audio and video. But in our scope is also to satisfy RFC 6881, and there is also messaging specified. There may be users who have not enabled real-time text but are used to text messaging, and want to use that in an emergency situation. These would also fall beside the implicit linking between m-line media names and media. Shall we bother about them? This can be solved by a coding rule that makes an explicit difference between text and spoken modality, either in the language tags or in the attribute names. By that it would be clear what modality a humintlang attribute indicated even if it was hooked on to a media-agnostic media specification. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Sun Oct 4 00:59:42 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D671A6F93 for ; Sun, 4 Oct 2015 00:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyAjARmmzNLs for ; Sun, 4 Oct 2015 00:59:37 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EB11A6F64 for ; Sun, 4 Oct 2015 00:59:36 -0700 (PDT) X-Halon-ID: d79bc5ea-6a6d-11e5-bfe4-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 4 Oct 2015 09:59:29 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5610DC61.5020005@omnitor.se> Date: Sun, 4 Oct 2015 09:59:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030208040509010203050302" Archived-At: Subject: [Slim] The use of multiple lang attributes in SDP X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 07:59:41 -0000 This is a multi-part message in MIME format. --------------030208040509010203050302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I have looked a bit further into the vague specification of use of multiple a= lang attributes in SDP, as discussed in section 6 of https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02 My conclusion is that we can safely assume that for real-time sessions, the meaning of multiple lang specifications is a range of capabilities, and not a requirement to use all languages as the current interpretation in the draft leans towards. By that interpretation, we can also assume that an offer/answer exchange can negotiate the language(s) to use in a session to be a subset of what the offer contained. The wording from RFC 4566, repeated in the draft, section 6 is: " Multiple lang attributes can be provided either at session or media level if the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important." I traced the introduction of the wording from an announcement in mmusic on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on 1997-12-23. There was no further discussion and the wording has stayed like that since then. In the mail announcing the introduction it was said that the intention was to fulfill requirements from a draft by Harald Alvestrand that then became RFC 2277. A relevant section in RFC 2277 is: " 4.4. Considerations for language negotiation Protocols where users have text presented to them in response to user actions MUST provide for support of multiple languages. How this is done will vary between protocols; for instance, in some cases, a negotiation where the client proposes a set of languages and the server replies with one is appropriate; in other cases, a server may choose to send multiple variants of a text and let the client pick which one to display. Negotiation is useful in the case where one side of the protocol exchange is able to present text in multiple languages to the other side, and the other side has a preference for one of these; the most common example is the text part of error responses, or Web pages that are available in multiple languages. Negotiating a language should be regarded as a permanent requirement of the protocol that will not go away at any time in the future. In many cases, it should be possible to include it as part of the connection establishment, together with authentication and other preferences negotiation. " So it is apparent that the intention for real-time conversational cases is a negotiation with an offer and a selection, either in an answer or by human agreement in the session. The central word creating the current interpretation in our draft that all languages must be used is "use" in this phrase: "if the session description or media*use* multiple languages". It is hard to believe that that was the intention. A very simple change makes it more realistic: "if the session or media*can* *use* multiple languages". There are multiple reasons for that interpretation: 1. It aligns with the requirement for language negotiation in RFC 2277 that was said to be the requirement behind the wording. 2. It is usually unrealistic to use multiple languages at the same time in a medium. It is more in line with real-time conversation that events during the conversation causes decision to use just one language. 3. The following discussion of importance of languages lose its meaning if all must be used. "the order of the attributes indicates the order of importance of the various languages in the session or media". There is no use of knowing how important a language is if they all must be presented. It is more likely that this relates to a possibility to select and the importance is a grading of preference. This would mean that we can safely assume that the use of multiple lang attributes in SDP are intended as a selection and negotiation through offer/answer. To put this assumption in words, we could either just insert the word "can" in the sentence from RFC 4566, or make a more elaborated rewording, e.g. into: " Multiple lang attributes can be provided either at session or media level if the session or media has capability to use multiple languages, in which case the order of the attributes indicates the order of preference of the various possible languages in the session or media from most preferred to least preferred. Events during the session may influence which language(s) are used, and for real-time sessions, the participants are not strictly bound to only use the declared languages." ( the last sentence was inspired from a similar specification, I do not remember from where. It may have been from CLUE or XCON ) Which wording do you prefer? Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft? If the reasoning above is accepted in slim, it would require changes in section 6 of the draft and open for some use of the current lang attributes for simple cases. But since we do not get directionality from the current attributes, there is still a need to add the humintlang attributes. /Gunnar --------------030208040509010203050302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I have looked a bit further into the vague specification of use of multiple a= lang attributes in SDP, as discussed in section 6 of
https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02

My conclusion is that we can safely assume that for real-time sessions, the meaning of multiple lang specifications is a range of capabilities, and not a requirement to use all languages as the current interpretation in the draft leans towards.
By that interpretation, we can also assume that an offer/answer exchange can negotiate the language(s) to use in a session to be a subset of what the offer contained.

The wording from RFC 4566, repeated in the draft, section 6 is:

"
Multiple lang attributes can be
      provided either at session or media level if the session
      description or media use multiple languages, in which case the
      order of the attributes indicates the order of importance of the
      various languages in the session or media from most important to
      least important."

I traced the introduction of the wording from an announcement in mmusic on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on 1997-12-23. There was no further discussion and the wording has stayed like that since then.

In the mail announcing the introduction it was said that the intention was to fulfill requirements from a draft by Harald Alvestrand that then became RFC 2277.

A relevant section in RFC 2277 is:
"
4.4.  Considerations for language negotiation

   Protocols where users have text presented to them in response to user
   actions MUST provide for support of multiple languages.

   How this is done will vary between protocols; for instance, in some
   cases, a negotiation where the client proposes a set of languages and
   the server replies with one is appropriate; in other cases, a server
   may choose to send multiple variants of a text and let the client
   pick which one to display.

   Negotiation is useful in the case where one side of the protocol
   exchange is able to present text in multiple languages to the other
   side, and the other side has a preference for one of these; the most
   common example is the text part of error responses, or Web pages that
   are available in multiple languages.

   Negotiating a language should be regarded as a permanent requirement
   of the protocol that will not go away at any time in the future.

   In many cases, it should be possible to include it as part of the
   connection establishment, together with authentication and other
   preferences negotiation. "

So it is apparent that the intention for real-time conversational cases is a negotiation with
 an offer and a selection, either in an answer or by human agreement in the session.

The central word creating the current interpretation in our draft that all languages must be used is "use" in this phrase:
"if the session description or media use multiple languages". 

It is hard to believe that that was the intention. A very simple change makes it more realistic:
"if the session or media can use multiple languages".

There are multiple reasons for that interpretation:

1. It aligns with the requirement for language negotiation in RFC 2277 that was said to be 
   the requirement behind the wording.
2. It is usually unrealistic to use multiple languages at the same time in a medium. 
   It is more in line with real-time conversation that events during the conversation causes decision to use
   just one language.

3. The following discussion of importance of languages lose its meaning if all must be used. "the
order of the attributes indicates the order of importance of the various languages in the session or media".
There is no use of knowing how important a language is if they all must be presented. It is more likely that
this relates to a possibility to select and the importance is a grading of preference.

This would mean that we can safely assume that the use of multiple lang attributes in SDP are intended as 
a selection and negotiation through offer/answer. 

To put this assumption in words, we could either just insert the word "can" in the sentence from RFC 4566, 
or make a more elaborated rewording, e.g. into:

" Multiple lang attributes can be provided either at session or media level if the session or media has 
capability to use multiple languages, in which case the order of the attributes indicates the order of 
preference of the various possible languages in the session or media from most preferred to least preferred.
Events during the session may influence which language(s) are used, and for real-time sessions, the
participants are not strictly bound to only use the declared languages."

( the last sentence was inspired from a similar specification, I do not remember from where. It may have been from CLUE or XCON )

Which wording do you prefer?

Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft?

If the reasoning above is accepted in slim, it would require changes in section 6 of the draft and open for some 
use of the current lang attributes for simple cases. But since we do not get directionality from the current attributes,
there is still a need to add the humintlang attributes.

/Gunnar
--------------030208040509010203050302-- From nobody Sun Oct 4 03:27:42 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4B01AC447 for ; Sun, 4 Oct 2015 03:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhEE7ZovVZL2 for ; Sun, 4 Oct 2015 03:27:39 -0700 (PDT) Received: from bin-vsp-out-05.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 9030C1AC446 for ; Sun, 4 Oct 2015 03:27:38 -0700 (PDT) X-Halon-ID: 86f5fbc5-6a82-11e5-b53c-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 4 Oct 2015 12:27:34 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5610FF14.8080100@omnitor.se> Date: Sun, 4 Oct 2015 12:27:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Slim] Relative preference between media X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 10:27:41 -0000 A feature lacking from the current real-time slim draft is to specify relative preference between media. Only relative preference between different languages in the same modality is currently possible. The lack of that feature makes it not possible to specify combinations as: "I prefer to use sign language but can accept to communicate in text", "I prefer to use speech, but have some sign language competence", "I prefer to speak, and receive text, but can as last resort use hearing for reception". etc. Some of these are quite essential for the usefulness of our indications. I have requested earlier that we should assign an indication of a simple absolute preference per language tag, e.g. in three levels. "stongly preferred", "can use" and "may use with low preference". I have now realized that by introducing a possibility to use the language tags on the session level and have references to labels in m-lines to show what medium they refer to, we can solve both the need for relative preference between modalities, and get a well condensed language indication block that is easy to parse for negotiating and gatewaying. However, it does not enable any absolute grading of preference, and will sometimes imply a false grading of preference when the preferences are equal between alternatives. Anyway it is a useful alternative to the absolute preference grading, so this is the proposal: Allow use of the humintlang attribute on SDP session level, and let the order of the attributes show a relative preference to use that language. Define a parameter to the humintlang attribute for a label, referring to a media specification in the SDP, e.g. in this way: a=humintlang-send: mstrm: a=humintlang-recv: mstrm: m=audio ... a=label: ... m=text ... a=label: The intention is to use labels defined in RFC 4574 in a similar way as in RFC 4583. We would then also need to define how a mix of lang= and humintlang= attributes shall be handled, and discuss if we can make it possible to also use the label parameter on lang= attributes. /Gunnar From nobody Sun Oct 4 09:47:15 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C381B29E5 for ; Sun, 4 Oct 2015 09:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFMxxUX_zKnp for ; Sun, 4 Oct 2015 09:47:11 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DEA1B29E2 for ; Sun, 4 Oct 2015 09:47:11 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-10v.sys.comcast.net with comcast id R4nA1r0032GyhjZ014nAeC; Sun, 04 Oct 2015 16:47:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id R4n91r00S3Ge9ey014nAFG; Sun, 04 Oct 2015 16:47:10 +0000 To: slim@ietf.org References: <5610DC61.5020005@omnitor.se> From: Paul Kyzivat Message-ID: <5611580D.1050309@alum.mit.edu> Date: Sun, 4 Oct 2015 12:47:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5610DC61.5020005@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1443977230; bh=Z9joZb9ryXH6gagY2HVnHvhS1BlzyLFjcPGd0ds45mM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nlt/0JYdvNBHBng1CO/Qmp4jxGBzIJbZlYIZiOEqXZ8D8oNj0tYFoK1VGof+XSdjr fNsmJpnYoLIAPFMJFQ9BqyEwYVbzdytXzczhb1p6BsKzCUA8WxP5s7vL1Noe0M8UWU kYh2t0MSM2kamCpJ4C15jQymH62kBApTPlStykYmdSi2uqlkPOrs+Y+Ied2VsHKIIz FAjxf7T1RR64tlZ8ocwNw/yTUPr0660dwmvrKNBZyHhkZ4TQbJKu4kiGdjAiGEC8F6 jHFopTKwFMcaCSaYiSwN2E+McRGJP8AYr2fxLhhHVhx3ovw4mC4WLZId0SS3D9XnWq 9O7TYyiZdf6UA== Archived-At: Subject: Re: [Slim] The use of multiple lang attributes in SDP X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 16:47:13 -0000 On 10/4/15 3:59 AM, Gunnar Hellström wrote: > I have looked a bit further into the vague specification of use of > multiple a= lang attributes in SDP, as discussed in section 6 of > https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02 > > My conclusion is that we can safely assume that for real-time sessions, > the meaning of multiple lang specifications is a range of capabilities, > and not a requirement to use all languages as the current interpretation > in the draft leans towards. > By that interpretation, we can also assume that an offer/answer exchange > can negotiate the language(s) to use in a session to be a subset of what > the offer contained. > > The wording from RFC 4566, repeated in the draft, section 6 is: > > " > > Multiple lang attributes can be > provided either at session or media level if the session > description or media use multiple languages, in which case the > order of the attributes indicates the order of importance of the > various languages in the session or media from most important to > least important." > > > I traced the introduction of the wording from an announcement in mmusic > on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 > on 1997-12-23. There was no further discussion and the wording has > stayed like that since then. > > In the mail announcing the introduction it was said that the intention > was to fulfill requirements from a draft by Harald Alvestrand that then > became RFC 2277. > > A relevant section in RFC 2277 is: > " > > 4.4. Considerations for language negotiation > > Protocols where users have text presented to them in response to user > actions MUST provide for support of multiple languages. > > How this is done will vary between protocols; for instance, in some > cases, a negotiation where the client proposes a set of languages and > the server replies with one is appropriate; in other cases, a server > may choose to send multiple variants of a text and let the client > pick which one to display. > > Negotiation is useful in the case where one side of the protocol > exchange is able to present text in multiple languages to the other > side, and the other side has a preference for one of these; the most > common example is the text part of error responses, or Web pages that > are available in multiple languages. > > Negotiating a language should be regarded as a permanent requirement > of the protocol that will not go away at any time in the future. > > In many cases, it should be possible to include it as part of the > connection establishment, together with authentication and other > preferences negotiation. " > > So it is apparent that the intention for real-time conversational cases is a negotiation with > an offer and a selection, either in an answer or by human agreement in the session. > > The central word creating the current interpretation in our draft that all languages must be used is "use" in this phrase: > "if the session description or media*use* multiple languages". > > It is hard to believe that that was the intention. A very simple change makes it more realistic: > "if the session or media*can* *use* multiple languages". > > There are multiple reasons for that interpretation: > > 1. It aligns with the requirement for language negotiation in RFC 2277 that was said to be > the requirement behind the wording. > 2. It is usually unrealistic to use multiple languages at the same time in a medium. > It is more in line with real-time conversation that events during the conversation causes decision to use > just one language. > > 3. The following discussion of importance of languages lose its meaning if all must be used. "the > order of the attributes indicates the order of importance of the various languages in the session or media". > There is no use of knowing how important a language is if they all must be presented. It is more likely that > this relates to a possibility to select and the importance is a grading of preference. > > This would mean that we can safely assume that the use of multiple lang attributes in SDP are intended as > a selection and negotiation through offer/answer. > > To put this assumption in words, we could either just insert the word "can" in the sentence from RFC 4566, > or make a more elaborated rewording, e.g. into: > > " Multiple lang attributes can be provided either at session or media level if the session or media has > capability to use multiple languages, in which case the order of the attributes indicates the order of > preference of the various possible languages in the session or media from most preferred to least preferred. > Events during the session may influence which language(s) are used, and for real-time sessions, the > participants are not strictly bound to only use the declared languages." > > ( the last sentence was inspired from a similar specification, I do not remember from where. It may have been from CLUE or XCON ) > > Which wording do you prefer? > > Is it realistic to propose an errata to rfc 4566 for this kind of diffuse interpretation issue, or is it sufficient to declare the interpretation in our draft? Since a bis for rfc4566 is underway, any clarifications should be done there. Thanks, Paul > If the reasoning above is accepted in slim, it would require changes in section 6 of the draft and open for some > use of the current lang attributes for simple cases. But since we do not get directionality from the current attributes, > there is still a need to add the humintlang attributes. > > /Gunnar > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Sun Oct 4 11:33:39 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1A1B347A for ; Sun, 4 Oct 2015 11:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ltfLglloa3Z for ; Sun, 4 Oct 2015 11:33:35 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35C61B345B for ; Sun, 4 Oct 2015 11:33:34 -0700 (PDT) X-Halon-ID: 6854934e-6ac6-11e5-b25c-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 4 Oct 2015 20:33:29 +0200 (CEST) To: slim@ietf.org References: <5610DC61.5020005@omnitor.se> <5611580D.1050309@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <561170F7.9000400@omnitor.se> Date: Sun, 4 Oct 2015 20:33:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5611580D.1050309@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] The use of multiple lang attributes in SDP X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 18:33:38 -0000 Paul, Thanks for the reminder that there is a 4566bis on the way. I will make a proposal to mmusic. /Gunnar Den 2015-10-04 kl. 18:47, skrev Paul Kyzivat: > On 10/4/15 3:59 AM, Gunnar Hellström wrote: >> I have looked a bit further into the vague specification of use of >> multiple a= lang attributes in SDP, as discussed in section 6 of >> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02 >> >> >> My conclusion is that we can safely assume that for real-time sessions, >> the meaning of multiple lang specifications is a range of capabilities, >> and not a requirement to use all languages as the current interpretation >> in the draft leans towards. >> By that interpretation, we can also assume that an offer/answer exchange >> can negotiate the language(s) to use in a session to be a subset of what >> the offer contained. >> >> The wording from RFC 4566, repeated in the draft, section 6 is: >> >> " >> >> Multiple lang attributes can be >> provided either at session or media level if the session >> description or media use multiple languages, in which case the >> order of the attributes indicates the order of importance of the >> various languages in the session or media from most important to >> least important." >> >> >> I traced the introduction of the wording from an announcement in mmusic >> on 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 >> on 1997-12-23. There was no further discussion and the wording has >> stayed like that since then. >> >> In the mail announcing the introduction it was said that the intention >> was to fulfill requirements from a draft by Harald Alvestrand that then >> became RFC 2277. >> >> A relevant section in RFC 2277 is: >> " >> >> 4.4. Considerations for language negotiation >> >> Protocols where users have text presented to them in response to >> user >> actions MUST provide for support of multiple languages. >> >> How this is done will vary between protocols; for instance, in some >> cases, a negotiation where the client proposes a set of languages >> and >> the server replies with one is appropriate; in other cases, a server >> may choose to send multiple variants of a text and let the client >> pick which one to display. >> >> Negotiation is useful in the case where one side of the protocol >> exchange is able to present text in multiple languages to the other >> side, and the other side has a preference for one of these; the most >> common example is the text part of error responses, or Web pages >> that >> are available in multiple languages. >> >> Negotiating a language should be regarded as a permanent requirement >> of the protocol that will not go away at any time in the future. >> >> In many cases, it should be possible to include it as part of the >> connection establishment, together with authentication and other >> preferences negotiation. " >> >> So it is apparent that the intention for real-time conversational >> cases is a negotiation with >> an offer and a selection, either in an answer or by human agreement >> in the session. >> >> The central word creating the current interpretation in our draft >> that all languages must be used is "use" in this phrase: >> "if the session description or media*use* multiple languages". >> >> It is hard to believe that that was the intention. A very simple >> change makes it more realistic: >> "if the session or media*can* *use* multiple languages". >> >> There are multiple reasons for that interpretation: >> >> 1. It aligns with the requirement for language negotiation in RFC >> 2277 that was said to be >> the requirement behind the wording. >> 2. It is usually unrealistic to use multiple languages at the same >> time in a medium. >> It is more in line with real-time conversation that events during >> the conversation causes decision to use >> just one language. >> >> 3. The following discussion of importance of languages lose its >> meaning if all must be used. "the >> order of the attributes indicates the order of importance of the >> various languages in the session or media". >> There is no use of knowing how important a language is if they all >> must be presented. It is more likely that >> this relates to a possibility to select and the importance is a >> grading of preference. >> >> This would mean that we can safely assume that the use of multiple >> lang attributes in SDP are intended as >> a selection and negotiation through offer/answer. >> >> To put this assumption in words, we could either just insert the word >> "can" in the sentence from RFC 4566, >> or make a more elaborated rewording, e.g. into: >> >> " Multiple lang attributes can be provided either at session or media >> level if the session or media has >> capability to use multiple languages, in which case the order of the >> attributes indicates the order of >> preference of the various possible languages in the session or media >> from most preferred to least preferred. >> Events during the session may influence which language(s) are used, >> and for real-time sessions, the >> participants are not strictly bound to only use the declared languages." >> >> ( the last sentence was inspired from a similar specification, I do >> not remember from where. It may have been from CLUE or XCON ) >> >> Which wording do you prefer? >> >> Is it realistic to propose an errata to rfc 4566 for this kind of >> diffuse interpretation issue, or is it sufficient to declare the >> interpretation in our draft? > > Since a bis for rfc4566 is underway, any clarifications should be done > there. > > Thanks, > Paul > >> If the reasoning above is accepted in slim, it would require changes >> in section 6 of the draft and open for some >> use of the current lang attributes for simple cases. But since we do >> not get directionality from the current attributes, >> there is still a need to add the humintlang attributes. >> >> /Gunnar >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Sun Oct 4 14:19:15 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533431A7020; Sun, 4 Oct 2015 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekH1O4UqCobU; Sun, 4 Oct 2015 14:19:13 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 2C0B31A701E; Sun, 4 Oct 2015 14:19:13 -0700 (PDT) Received: by vkao3 with SMTP id o3so85886786vka.2; Sun, 04 Oct 2015 14:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nTblv74Eb6nk4GpKyQwBWM/VBQ2LLf7gPMA/m2MU7DI=; b=sYV+GbSBo1noEykzLDpoUo0f4b7CwB5HRXObFm1dTvKhRF8iDTZL6WrtFOzDrHYVfs J8xe5LNyoahjRH5vKz2IvpZAQGliNBIS9FHfK0BKkLtFxENggHVwtGczRzD5d4J07FPx kNbn1ZGjgOiBto4nHRVMcrafzlybg34tHEyrVLSjaYEv+OlQJpqqv9Zyt3an2re4VwhC Lq9P9Vye61lHCCDZeLEQqAa5oeZCWY40dtdLI4xkCp9h3oAOD5xteSXHmbVpHyNUp7nt bUBytrczOmXNcsQo4gSFDSX8b2k6cu3iNltzkf/sYyqWCr2I3QS8opPJ55UVvelBk1C7 MIGw== MIME-Version: 1.0 X-Received: by 10.31.192.9 with SMTP id q9mr17638829vkf.63.1443993552241; Sun, 04 Oct 2015 14:19:12 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Sun, 4 Oct 2015 14:19:12 -0700 (PDT) In-Reply-To: <560E4460.4030407@cs.tcd.ie> References: <560988C3.6080402@omnitor.se> <5609BBA6.9080101@cs.tcd.ie> <560AAFB2.4060805@cs.tcd.ie> <560AFD5A.5060101@cs.tcd.ie> <560B8CC1.2060405@cs.tcd.ie> <560C0716.8050404@alum.mit.edu> <476BCA21-7802-4E39-A22A-835BE66E15E8@brianrosen.net> <560C1019.80509@alum.mit.edu> <560C1436.6080200@omnitor.se> <560E4460.4030407@cs.tcd.ie> Date: Sun, 4 Oct 2015 17:19:12 -0400 X-Google-Sender-Auth: 4rcgCD0vl4N9F5LvyjyMEIgiclM Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 21:19:14 -0000 > I'm asking that the analysis be somewhat broader than only > considering language. (On the basis that if we define how to > add language then other personal attributes are likely to > be similarly handled in the relevant protocols, UAs and servers.) > If one did agree with that then I do think it ought be included > in the charter. ... > Right, I get that the gating thing is iccky, and Bernard rightly > points out that even when we try do all that well, the end results > might not be so great, which is a totally fair point. OK... given all that, I, at least, can support asking the working group to do that kind of analysis, and including it in the charter. I'm just one voice, so I'd like to hear from the people who will actually do the work. In any case, I'm certain that we will need people from the Security Area to work on this in the working group, if it's going to be of any real value, and I have to ask the Security ADs to make sure we have that -- more than one person, I think, and people who will take an active role. > How about something like this: > > "It is not unlikely that once there is a method for using language > as planned here, some implementations may similarly handle other > personal attributes. The wg will analyse the security and privacy > issues arising from having UAs emit language or other similar > attributes and then handle language attributes accordingly." How does this work, appended to the charter (at the end)?: "Adding language information to the control streams will have security and privacy implications that must be understood and documented, as any protocol would have to do. Beyond that, this may open the door to inclusion of other information that could be more security- or privacy-sensitive than language preferences, and it could be important to have a close look at that early on. Therefore, this working group will include in its work a broader analysis of security and privacy implications of including such information in this manner. That analysis may be written as a separate document, or may be included in the working group's primary document(s). The Security Area will provide necessary ongoing participation for that analysis, and this requirement will not block progress on the working group's main work if such participation is not available." Maybe wordier than it needs to be, but I'd like to be clear. Barry From nobody Sun Oct 4 14:22:46 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E401A86DF; Sun, 4 Oct 2015 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrHxxAH-B94q; Sun, 4 Oct 2015 14:22:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17401A86E8; Sun, 4 Oct 2015 14:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD928BEE5; Sun, 4 Oct 2015 22:22:39 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZid3O55h8_C; Sun, 4 Oct 2015 22:22:38 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.22.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0365BEE3; Sun, 4 Oct 2015 22:22:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1443993758; bh=oFOjMncRCOyvme+mpmtEYp60u5JQpMKvjlj0cMxHZU4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OPDMZaRwsIipHdav9Z17gIAP3X8pS64xArFDVCvI+PVT7+Y8zBYK/BtvWdagGsAIu w06SMbee4Zi1qNS6tBabw4bIREBhNg7Dc+Sn2wmOeNRRALJV/S+cX0lPeJtNLtqilk 5XAeR1GnQqvmlJS0LciC5TddhW68M3ZOHNqBGAKc= To: Barry Leiba References: <560988C3.6080402@omnitor.se> <5609BBA6.9080101@cs.tcd.ie> <560AAFB2.4060805@cs.tcd.ie> <560AFD5A.5060101@cs.tcd.ie> <560B8CC1.2060405@cs.tcd.ie> <560C0716.8050404@alum.mit.edu> <476BCA21-7802-4E39-A22A-835BE66E15E8@brianrosen.net> <560C1019.80509@alum.mit.edu> <560C1436.6080200@omnitor.se> <560E4460.4030407@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5611989D.9040504@cs.tcd.ie> Date: Sun, 4 Oct 2015 22:22:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 21:22:44 -0000 On 04/10/15 22:19, Barry Leiba wrote: >> I'm asking that the analysis be somewhat broader than only >> considering language. (On the basis that if we define how to >> add language then other personal attributes are likely to >> be similarly handled in the relevant protocols, UAs and servers.) >> If one did agree with that then I do think it ought be included >> in the charter. > ... >> Right, I get that the gating thing is iccky, and Bernard rightly >> points out that even when we try do all that well, the end results >> might not be so great, which is a totally fair point. > > OK... given all that, I, at least, can support asking the working > group to do that kind of analysis, and including it in the charter. > I'm just one voice, so I'd like to hear from the people who will > actually do the work. In any case, I'm certain that we will need > people from the Security Area to work on this in the working group, if > it's going to be of any real value, and I have to ask the Security ADs > to make sure we have that -- more than one person, I think, and people > who will take an active role. > >> How about something like this: >> >> "It is not unlikely that once there is a method for using language >> as planned here, some implementations may similarly handle other >> personal attributes. The wg will analyse the security and privacy >> issues arising from having UAs emit language or other similar >> attributes and then handle language attributes accordingly." > > How does this work, appended to the charter (at the end)?: > > "Adding language information to the control streams will have security > and privacy implications that must be understood and documented, as > any protocol would have to do. Beyond that, this may open the door to > inclusion of other information that could be more security- or > privacy-sensitive than language preferences, and it could be important > to have a close look at that early on. Therefore, this working group > will include in its work a broader analysis of security and privacy > implications of including such information in this manner. That > analysis may be written as a separate document, or may be included in > the working group's primary document(s). The Security Area will > provide necessary ongoing participation for that analysis, and this > requirement will not block progress on the working group's main work > if such participation is not available." > > Maybe wordier than it needs to be, but I'd like to be clear. Yep, but I could go with that anyway. And I'll try get folks who'll help. And I accept that there's a chance we won't succeed in getting a useful or any analysis done. Cheers, S. > > Barry > From nobody Sun Oct 4 16:44:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8DB1B368E for ; Sun, 4 Oct 2015 16:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.9 X-Spam-Level: * X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdKzriypcU99 for ; Sun, 4 Oct 2015 16:44:33 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79711B368C for ; Sun, 4 Oct 2015 16:44:32 -0700 (PDT) Received: from ppp118-209-32-8.lns20.mel4.internode.on.net ([118.209.32.8]:49943 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZisxC-003bFd-53 for slim@ietf.org; Mon, 05 Oct 2015 10:44:30 +1100 To: slim@ietf.org References: <560FA86D.8080201@omnitor.se> From: Christian Groves Message-ID: <5611B9DC.1030706@nteczone.com> Date: Mon, 5 Oct 2015 10:44:28 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560FA86D.8080201@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 23:44:34 -0000 Hello Gunnar, It would be possible to "hook" the humanlang attributes to the specific instance of the datachannel. You simply use the humanlang tags in the dcsa attribute. The protocol is indicated via the subprotocol element in the dcmap attribute. E.g. m=application 911 /DTLS/SCTP webrtc-datachannel c=IN IP4 11.9.19.65 a=max-message-size:1000 ; a=sctp-port 5000 a=dcmap:1 label="text conversation";subprotocol="t140" a=dcsa:1 cps=30 ; "the RFC4103 default value as example" a=dcsa:1 humintlang-send: a=dcsa:1 humintlang-recv: Regards, Christian On 3/10/2015 8:05 PM, Gunnar Hellström wrote: > The limitations of having the language indications in SDP is eternally > popping up as a problem when planning its use. > I know that this has been discussed a lot in the past and that we have > agreed to go the SDP path. > > But I want to question it again. > I got a reminder from reviewing the latest specification of real-time > text in WebRTC. > https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02 > > > There, the real-time text stream is a subchannel multiplexed in the > WebRTC data channel, with sdp-specification m=application. > So, there is no m=text to hook our humintlang attributes on. > > It is quite likely that WebRTC terminals will be used in situations > where language negotiation is desirable. > If we keep it under SDP, we would then need to define some mapping > rules between languages for media not appearing under their original > m= names. > A tempting alternative is to move the whole language indication to an > XML block carried in a defined place, so that it can be reused in > different environments. > > Gunnar > From nobody Sun Oct 4 19:57:16 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088A1B40E3; Sun, 4 Oct 2015 19:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42bJ4-42kWEK; Sun, 4 Oct 2015 19:57:12 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 E47531B40E0; Sun, 4 Oct 2015 19:57:11 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so165145909pac.2; Sun, 04 Oct 2015 19:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rGkNvIBdO+Be6NxNpv+XwQkele9H6FC+n7oWw+zTq2o=; b=g4I6timAXUR3fguO+xQSAcwaeUfxUZ+ZjYPBRcZqcJlyUILVL8ZXNDe3rVflOy7gyz de7WzJvLy2jeFskp6ndaotXCDP1RwLit2HfcEbCKtHJ0gE7NhmD0mxFpJEvXjuNkg8pW TwfIBMhP+zt7As0aLcmzodWk2iOzZqCXHY1UQqdXV88GVQTgotYD52uiyWVV0HShVztH lz96xgvCOCquOl77aBZiaPlGchSrw0DkVIn5tOji/hVHFWjLR5Xjhs5yla/2UgcGFAsv kOASuAAMLH5ndLOLBNQmO8yxNaX6U7S8Df+vxDzy33CR15NkDkTp13qb5BUxVPbC7laT jM4A== X-Received: by 10.66.234.138 with SMTP id ue10mr37268185pac.9.1444013830631; Sun, 04 Oct 2015 19:57:10 -0700 (PDT) Received: from [192.168.1.149] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id ja4sm24364056pbb.19.2015.10.04.19.57.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Oct 2015 19:57:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13A452) In-Reply-To: <5611989D.9040504@cs.tcd.ie> Date: Sun, 4 Oct 2015 19:57:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0607DCA9-8148-4F31-9B00-81CEDBBDFB47@gmail.com> References: <560988C3.6080402@omnitor.se> <5609BBA6.9080101@cs.tcd.ie> <560AAFB2.4060805@cs.tcd.ie> <560AFD5A.5060101@cs.tcd.ie> <560B8CC1.2060405@cs.tcd.ie> <560C0716.8050404@alum.mit.edu> <476BCA21-7802-4E39-A22A-835BE66E15E8@brianrosen.net> <560C1019.80509@alum.mit.edu> <560C1436.6080200@omnitor.se> <560E4460.4030407@cs.tcd.ie> <5611989D.9040504@cs.tcd.ie> To: Barry Leiba Archived-At: Cc: slim@ietf.org, IESG Subject: Re: [Slim] Stephen Farrell's Block on charter-ietf-slim-00-06: (with BLOCK) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 02:57:13 -0000 > On 04/10/15 22:19, Barry Leiba wrote: >>=20 >>=20 >>> How about something like this: >>>=20 >>> "It is not unlikely that once there is a method for using language >>> as planned here, some implementations may similarly handle other >>> personal attributes. The wg will analyse the security and privacy >>> issues arising from having UAs emit language or other similar >>> attributes and then handle language attributes accordingly." >>=20 >> How does this work, appended to the charter (at the end)?: [BA] Support for language negotiation in SDP is not new.=20 a=3Dlang was first defined in RFC 2327, published in April 1998.=20 Since then, this has been included in RFC 4566, published in July 2006, and w= ill be included again in RFC 4566bis which is underway. RFC 1766, published in July 1995, defines language tags based on ISO 639/316= 6.=20 Given that language negotiation in SDP is 17+ years old, charter language th= at suggests it is a new problem, or ignores all the security considerations t= hat have already been written (and all prior IESG reviews) strains credulity= . =20 From nobody Sun Oct 4 23:48:03 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F371F1B49E8 for ; Sun, 4 Oct 2015 23:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj5O7hVCbKpJ for ; Sun, 4 Oct 2015 23:47:59 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763211B49E5 for ; Sun, 4 Oct 2015 23:47:58 -0700 (PDT) X-Halon-ID: 00ac775c-6b2d-11e5-bfe4-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Mon, 5 Oct 2015 08:47:53 +0200 (CEST) To: slim@ietf.org References: <560FA86D.8080201@omnitor.se> <5611B9DC.1030706@nteczone.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56121D19.8000103@omnitor.se> Date: Mon, 5 Oct 2015 08:47:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5611B9DC.1030706@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 06:48:02 -0000 Den 2015-10-05 kl. 01:44, skrev Christian Groves: > Hello Gunnar, > > It would be possible to "hook" the humanlang attributes to the > specific instance of the datachannel. You simply use the humanlang > tags in the dcsa attribute. The protocol is indicated via the > subprotocol element in the dcmap attribute. E.g. > > m=application 911 /DTLS/SCTP webrtc-datachannel > c=IN IP4 11.9.19.65 > a=max-message-size:1000 ; > a=sctp-port 5000 > a=dcmap:1 label="text conversation";subprotocol="t140" > a=dcsa:1 cps=30 ; "the RFC4103 default value as example" > a=dcsa:1 humintlang-send: > a=dcsa:1 humintlang-recv: (GH) Thanks for the good hint. I tried to decode section 5.1.2 Sub-Protocol Specific Attributes in the data-channel-sdpneg draft to see if there is a need to specify somewhere that the lang and humintlang attributes are allowed in subprotocol="t140" environment. But I did not find the answer. The lang and humintlang attributes are not really subprotocol specific, even if there are SDP-media and data-subprotocols where they are meaningless. They are commonly useful in many stream specifications. So there is probably a need for another section in data-channel-sdpneg to tell about common attributes. The idea is however clear and useful. Thanks. That leaves us with a possibility to extend the use of lang and humintlang relatively easy into part of the WebRTC area. It requires a bit more application awareness of the negotiation parser. On the traditional SIP side we have so far said that under m=text, we have language attributes for text streams, while now it must know also that under a dcmap with subprotocol="t140" lang and humintlang specifications talk about text streams. It would help parsing a lot if we had an explicit way to differentiate written language from spoken language in the language tag itself. Can we revive that issue? /Gunnar > > Regards, Christian > > On 3/10/2015 8:05 PM, Gunnar Hellström wrote: >> The limitations of having the language indications in SDP is >> eternally popping up as a problem when planning its use. >> I know that this has been discussed a lot in the past and that we >> have agreed to go the SDP path. >> >> But I want to question it again. >> I got a reminder from reviewing the latest specification of real-time >> text in WebRTC. >> https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-02 >> >> >> There, the real-time text stream is a subchannel multiplexed in the >> WebRTC data channel, with sdp-specification m=application. >> So, there is no m=text to hook our humintlang attributes on. >> >> It is quite likely that WebRTC terminals will be used in situations >> where language negotiation is desirable. >> If we keep it under SDP, we would then need to define some mapping >> rules between languages for media not appearing under their original >> m= names. >> A tempting alternative is to move the whole language indication to an >> XML block carried in a defined place, so that it can be reused in >> different environments. >> >> Gunnar >> > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Mon Oct 5 09:45:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812231A1BFF for ; Mon, 5 Oct 2015 09:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l8sC0WBAy22 for ; Mon, 5 Oct 2015 09:45:28 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9A01A1BA3 for ; Mon, 5 Oct 2015 09:45:28 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-12v.sys.comcast.net with comcast id RUlM1r0015AAYLo01UlUQr; Mon, 05 Oct 2015 16:45:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id RUlT1r00H3Ge9ey01UlThk; Mon, 05 Oct 2015 16:45:28 +0000 To: slim@ietf.org References: <560FA86D.8080201@omnitor.se> <5611B9DC.1030706@nteczone.com> <56121D19.8000103@omnitor.se> From: Paul Kyzivat Message-ID: <5612A926.9020908@alum.mit.edu> Date: Mon, 5 Oct 2015 12:45:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56121D19.8000103@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444063528; bh=uk50Cdd3389vKlkzWhUokIvV/RuZ46K0+2k1d8k5wxQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=wFIy7ZhWKbxhSdbzdAs9DU21mICK/Jn/w0D+N2c7fa4tJnTEroPpfCy4AiYTPSo5c NR06DFiJTc1eC60BZ/R4Kl9J2zgpxA5LNNqz0C5dLN6LmOy8izsCm0x/XSBLPnRI+k 0SeGHlrI8apOCNxZTFGjF7NIBgvun5ISglrotGKgZ/6n2lny4Zs7jznn12sy7hgW0s 7jSgLTtCBfd6l5w7Siivy2dWPKSfMykVgguYm5WsspT94acrhlEVbdDaRfbdRU9j/c B+e7sA1jNFJzkBujyPPAKErOC522TMt5F46XnKYjtTiw0hj55BUIN4CV17yewaob4s pRLHVQ4qMlSSA== Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 16:45:29 -0000 Christian, > Den 2015-10-05 kl. 01:44, skrev Christian Groves: >> Hello Gunnar, >> >> It would be possible to "hook" the humanlang attributes to the >> specific instance of the datachannel. You simply use the humanlang >> tags in the dcsa attribute. The protocol is indicated via the >> subprotocol element in the dcmap attribute. E.g. >> >> m=application 911 /DTLS/SCTP webrtc-datachannel >> c=IN IP4 11.9.19.65 >> a=max-message-size:1000 ; >> a=sctp-port 5000 >> a=dcmap:1 label="text conversation";subprotocol="t140" >> a=dcsa:1 cps=30 ; "the RFC4103 default value as example" The above line can't be right. 'cps=30' doesn't conform to syntax of an attribute. >> a=dcsa:1 humintlang-send: >> a=dcsa:1 humintlang-recv: From nobody Mon Oct 5 15:39:39 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5ED1A6F99 for ; Mon, 5 Oct 2015 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFFLdhVttFiZ for ; Mon, 5 Oct 2015 15:39:36 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17FC1A6F7C for ; Mon, 5 Oct 2015 15:39:35 -0700 (PDT) X-Halon-ID: f0754a61-6bb1-11e5-98bf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 6 Oct 2015 00:39:29 +0200 (CEST) To: Paul Kyzivat , slim@ietf.org References: <560FA86D.8080201@omnitor.se> <5611B9DC.1030706@nteczone.com> <56121D19.8000103@omnitor.se> <5612A926.9020908@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5612FC20.3040809@omnitor.se> Date: Tue, 6 Oct 2015 00:39:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5612A926.9020908@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 22:39:38 -0000 Den 2015-10-05 kl. 18:45, skrev Paul Kyzivat: > Christian, > > > Den 2015-10-05 kl. 01:44, skrev Christian Groves: >>> Hello Gunnar, >>> >>> It would be possible to "hook" the humanlang attributes to the >>> specific instance of the datachannel. You simply use the humanlang >>> tags in the dcsa attribute. The protocol is indicated via the >>> subprotocol element in the dcmap attribute. E.g. >>> >>> m=application 911 /DTLS/SCTP webrtc-datachannel >>> c=IN IP4 11.9.19.65 >>> a=max-message-size:1000 ; >>> a=sctp-port 5000 >>> a=dcmap:1 label="text conversation";subprotocol="t140" >>> a=dcsa:1 cps=30 ; "the RFC4103 default value as example" > > The above line can't be right. 'cps=30' doesn't conform to syntax of > an attribute. Right, it is a subparameter in an fmtp attribute. fmtp is not of interest to carry over to the WebRTC side. So it likely needs to be specifically specified as a native attribute in the dat channel subprotocol. But that was not the point. It was that mapping of humintlang attributes to WebRTC RTT stream seem possible but it is no straightforward m=text to hook it on to on the WebRTC side. > >>> a=dcsa:1 humintlang-send: >>> a=dcsa:1 humintlang-recv: > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Mon Oct 5 16:40:18 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A741B3421 for ; Mon, 5 Oct 2015 16:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGQh7boEgknD for ; Mon, 5 Oct 2015 16:40:16 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2C51B30E4 for ; Mon, 5 Oct 2015 16:39:59 -0700 (PDT) Received: from ppp118-209-52-42.lns20.mel4.internode.on.net ([118.209.52.42]:50094 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZjFMK-003lbI-Fl; Tue, 06 Oct 2015 10:39:56 +1100 To: slim@ietf.org References: <560FA86D.8080201@omnitor.se> <5611B9DC.1030706@nteczone.com> <56121D19.8000103@omnitor.se> <5612A926.9020908@alum.mit.edu> <5612FC20.3040809@omnitor.se> From: Christian Groves Message-ID: <56130A49.4020308@nteczone.com> Date: Tue, 6 Oct 2015 10:39:53 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5612FC20.3040809@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "Schwarz, Albrecht \(Albrecht\)" Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 23:40:17 -0000 Hello Paul, On 6/10/2015 9:39 AM, Gunnar Hellström wrote: > Den 2015-10-05 kl. 18:45, skrev Paul Kyzivat: >> Christian, >> >> > Den 2015-10-05 kl. 01:44, skrev Christian Groves: >>>> Hello Gunnar, >>>> >>>> It would be possible to "hook" the humanlang attributes to the >>>> specific instance of the datachannel. You simply use the humanlang >>>> tags in the dcsa attribute. The protocol is indicated via the >>>> subprotocol element in the dcmap attribute. E.g. >>>> >>>> m=application 911 /DTLS/SCTP webrtc-datachannel >>>> c=IN IP4 11.9.19.65 >>>> a=max-message-size:1000 ; >>>> a=sctp-port 5000 >>>> a=dcmap:1 label="text conversation";subprotocol="t140" >>>> a=dcsa:1 cps=30 ; "the RFC4103 default value as example" >> >> The above line can't be right. 'cps=30' doesn't conform to syntax of >> an attribute. > Right, it is a subparameter in an fmtp attribute. fmtp is not of > interest to carry over to the WebRTC side. So it likely needs to be > specifically specified as a native attribute in the dat channel > subprotocol. > > > But that was not the point. It was that mapping of humintlang > attributes to WebRTC RTT stream seem possible but it is no > straightforward m=text to hook it on to on the WebRTC side. [CNG] It was a cut and paste from draft-schwarz-mmusic-t140-usage-data-channel. I didn't look at that part of the syntax. As Gunnar said I was just illustrating the concept of using attributes associated with a data channel. You're right though it doesn't conform. It probably should be something like a=dcsa:1 fmtp:- cps=30. I've cc'd Albrecht on this. Regards, Christian >> >>>> a=dcsa:1 humintlang-send: >>>> a=dcsa:1 humintlang-recv: >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Tue Oct 6 01:26:14 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67C61B3C3F for ; Tue, 6 Oct 2015 01:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57WrU8TkXinS for ; Tue, 6 Oct 2015 01:26:11 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526991B3C41 for ; Tue, 6 Oct 2015 01:26:11 -0700 (PDT) Received: from ppp118-209-52-42.lns20.mel4.internode.on.net ([118.209.52.42]:54648 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZjNZY-001EFy-Ft; Tue, 06 Oct 2015 19:26:08 +1100 To: "Schwarz, Albrecht (Albrecht)" , "slim@ietf.org" References: <560FA86D.8080201@omnitor.se> <5611B9DC.1030706@nteczone.com> <56121D19.8000103@omnitor.se> <5612A926.9020908@alum.mit.edu> <5612FC20.3040809@omnitor.se> <56130A49.4020308@nteczone.com> <786615F3A85DF44AA2A76164A71FE1ACDF796672@FR711WXCHMBA01.zeu.alcatel-lucent.com> From: Christian Groves Message-ID: <5613859B.9080101@nteczone.com> Date: Tue, 6 Oct 2015 19:26:03 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACDF796672@FR711WXCHMBA01.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "Makaraju, Maridi Raju \(Raju\)" , "Stoetzer-Bradler, Juergen \(Juergen\)" , "DRAGE, Keith \(Keith\)" Subject: Re: [Slim] SDP limitations X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 08:26:13 -0000 Hello Albrecht, Thanks must go to Paul for catching the fmtp one. Christian On 6/10/2015 6:34 PM, Schwarz, Albrecht (Albrecht) wrote: > Thanks for spotting the "a=dcsa" issue Christian! > > Will request MMUSIC to adopt > draft-schwarz-mmusic-t140-usage-data-channel > as WG draft and reply on the question below at MMUSIC. > Its an MMUSIC item and not SLIM in my understanding. > > Regards, > Albrecht > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Dienstag, 6. Oktober 2015 01:40 > To: slim@ietf.org > Cc: Schwarz, Albrecht (Albrecht) > Subject: Re: [Slim] SDP limitations > > Hello Paul, > > On 6/10/2015 9:39 AM, Gunnar Hellström wrote: >> Den 2015-10-05 kl. 18:45, skrev Paul Kyzivat: >>> Christian, >>> >>>> Den 2015-10-05 kl. 01:44, skrev Christian Groves: >>>>> Hello Gunnar, >>>>> >>>>> It would be possible to "hook" the humanlang attributes to the >>>>> specific instance of the datachannel. You simply use the humanlang >>>>> tags in the dcsa attribute. The protocol is indicated via the >>>>> subprotocol element in the dcmap attribute. E.g. >>>>> >>>>> m=application 911 /DTLS/SCTP webrtc-datachannel >>>>> c=IN IP4 11.9.19.65 >>>>> a=max-message-size:1000 ; >>>>> a=sctp-port 5000 >>>>> a=dcmap:1 label="text conversation";subprotocol="t140" >>>>> a=dcsa:1 cps=30 ; "the RFC4103 default value as example" >>> The above line can't be right. 'cps=30' doesn't conform to syntax of >>> an attribute. >> Right, it is a subparameter in an fmtp attribute. fmtp is not of >> interest to carry over to the WebRTC side. So it likely needs to be >> specifically specified as a native attribute in the dat channel >> subprotocol. >> >> >> But that was not the point. It was that mapping of humintlang >> attributes to WebRTC RTT stream seem possible but it is no >> straightforward m=text to hook it on to on the WebRTC side. > [CNG] It was a cut and paste from > draft-schwarz-mmusic-t140-usage-data-channel. I didn't look at that part of the syntax. As Gunnar said I was just illustrating the concept of using attributes associated with a data channel. > > You're right though it doesn't conform. It probably should be something like a=dcsa:1 fmtp:- cps=30. I've cc'd Albrecht on this. > > Regards, Christian >>>>> a=dcsa:1 humintlang-send: >>>>> a=dcsa:1 humintlang-recv: >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > From nobody Tue Oct 6 08:42:29 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ADF1A1A7E for ; Tue, 6 Oct 2015 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT7jHc12lCI9 for ; Tue, 6 Oct 2015 08:42:23 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B7F1A1A7C for ; Tue, 6 Oct 2015 08:42:22 -0700 (PDT) Received: by wicge5 with SMTP id ge5so172935737wic.0 for ; Tue, 06 Oct 2015 08:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=OP6dKUN6DO7A7CgIBLYgExb2L4P7uO93pr84/vYIcsc=; b=Ktfm6qyiqZ0cjbVFBVI8UknwYuIcFOswIxr+Yty7+BuHdNVT4SaArn13g2LhpDUjhZ mdC7xcXzWjLIBpt+UkjSDz/noxVUYozTpMTUTEe9vCMrGanTr71ssMy88JQn/SUwPD7H ecidaBouIuftELaVtCWZukz6uGTX43Gtg0AkDuts5uDrPRbUzImJwyMM8i5a59Cr+NVu ySsgm6kLlsDb/dGcJPxsmsUkNexhzkkkjq9lwZHsStkh1BrXgLu4xmIY5V95use20dzu wICtKcqnuvx7fyunv84t8ymdvF8rqEbXzfXFJqwdd8bHxzQtNs8IBuO673NXf6HQGKUo E6bQ== X-Received: by 10.194.121.1 with SMTP id lg1mr9603663wjb.111.1444146141303; Tue, 06 Oct 2015 08:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.13.106 with HTTP; Tue, 6 Oct 2015 08:42:01 -0700 (PDT) From: Bernard Aboba Date: Tue, 6 Oct 2015 10:42:01 -0500 Message-ID: To: Gunnar Hellstrom Content-Type: multipart/alternative; boundary=089e01177a2dc19d0c05217179d9 Archived-At: Cc: slim@ietf.org Subject: [Slim] Language negotiation and accessibility X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 15:42:27 -0000 --089e01177a2dc19d0c05217179d9 Content-Type: text/plain; charset=UTF-8 Gunnar said: "The limitations of having the language indications in SDP is eternally popping up as a problem when planning its use. I know that this has been discussed a lot in the past and that we have agreed to go the SDP path. But I want to question it again." [BA] Is there a good summary somewhere of language negotiation requirements relating to accessibility? --089e01177a2dc19d0c05217179d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0

"The limitations of having the language indications in SD= P is eternally popping up as a problem when planning its use.=C2=A0<= span style=3D"font-size:12.8px">I know that this has been discussed a lot i= n the past and that we have agreed to go the SDP path.
But I want to question it agai= n."

[BA] Is there a good summary somew= here of language negotiation requirements relating to accessibility? =C2=A0=
--089e01177a2dc19d0c05217179d9-- From nobody Thu Oct 8 07:07:09 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113161A0105 for ; Thu, 8 Oct 2015 07:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mII8PvwEP7aX for ; Thu, 8 Oct 2015 07:07:05 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E521A0117 for ; Thu, 8 Oct 2015 07:07:05 -0700 (PDT) Received: by wicge5 with SMTP id ge5so27518249wic.0 for ; Thu, 08 Oct 2015 07:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=CL0aBUYV0se/61BZAAsN1qjrL73lKgBKFlkCw5XA1n4=; b=bxRyT5Tb3muzeL3JZZKm/ln1Ke9lmDf0tuV0jUfR92p/qdXT5jTE2uqbatWmGuU/Pm yMit4bgxYfvVEO6k+cv3CTH38iVDos2QpRKUmrYFfxDDlTp2xb5krObrRrgYC632PZM1 k5owBRlAp5+pxKNKK0qPU8eBHinZt5+RkCva8vuqM1NWv6RN6aIdcKIUdZsNBaTdo2So n3Jm61m1MGcnYdD+te8oxnhGO6kFBi73Wi3LKBza+kShHWZ+9A6n3ybQQ9XAnQ/vgPS5 UgfMT+ve28b5U8yyhjH9YY2fIjeWSOWjHz38YIrauhJjfv3E2xYpNRFW1a7FEmqExitH BQtA== X-Received: by 10.180.88.168 with SMTP id bh8mr4092255wib.48.1444313224152; Thu, 08 Oct 2015 07:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.86.26 with HTTP; Thu, 8 Oct 2015 07:06:44 -0700 (PDT) From: Bernard Aboba Date: Thu, 8 Oct 2015 09:06:44 -0500 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=f46d0418265aab8f4a052198602c Archived-At: Cc: nrooney@gsma.com Subject: [Slim] Need for accommodation? X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 14:07:07 -0000 --f46d0418265aab8f4a052198602c Content-Type: text/plain; charset=UTF-8 The IETF is committed to accessibility, so as to allow full participation by individuals with disabilities. For the upcoming SLIM WG meeting (and for potential future virtual meetings), we would like to understand if there are participants who require accommodation (such as sign language interpretation). If you require accommodation, please send a note to myself and Natasha ( nrooney@gsma.com), so that we can work with you to make arrangements. --f46d0418265aab8f4a052198602c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The IETF is committed to accessibility, so as to allow ful= l participation by individuals with disabilities.=C2=A0

=
For the upcoming SLIM WG meeting (and for potential future virtual mee= tings), we would like to understand if there are participants who require a= ccommodation (such as sign language interpretation).=C2=A0
=
If you require accommodation, please send a note to myself a= nd Natasha (nrooney@gsma.com), so t= hat we can work with you to make arrangements.

--f46d0418265aab8f4a052198602c-- From nobody Thu Oct 8 08:00:49 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD2E1A6EE9 for ; Thu, 8 Oct 2015 08:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kyvXCLh-f46 for ; Thu, 8 Oct 2015 08:00:44 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B961A6EE8 for ; Thu, 8 Oct 2015 08:00:44 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-01v.sys.comcast.net with comcast id Seze1r0062Bo0NV01f0jal; Thu, 08 Oct 2015 15:00:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id Sf0i1r00Z3Ge9ey01f0j6X; Thu, 08 Oct 2015 15:00:43 +0000 To: slim@ietf.org References: From: Paul Kyzivat Message-ID: <56168519.20406@alum.mit.edu> Date: Thu, 8 Oct 2015 11:00:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444316443; bh=b1CWzoZiHIgt8r+nKHkRQaCNDgS0WAzOYFAJ4vfIRco=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jvQoajk1Fa6yiO1335s1gASB3V8yZa+vmia1WKzNrlc7XX1LymjjRqt0GcanXVbhv xqrPhuXhw6IrjMd6VYQF+IIRjDV+d8HoIYrSQ6y182zg7kc/JCm6mQkeXPimQE4Ns/ bFj8R6oKw6fV4R3anQImgAOknUKL+onxyZYWRiG7xf/UbUiegjObbWKiRoZs6y5YcX auvRBeDbX4fHo0tSGshCcwCDJ6XHAZsZu34qRN8WRL5ZtNh/XMqXhGIAI/UAehnJ2E kUszp3aIL79+8TFMpBX4gHsxeuXIInhxOLNygAdGh6Jr414SoZauHDMql7E+Jr5ish ovJOeBdU8+KkQ== Archived-At: Subject: Re: [Slim] Need for accommodation? X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 15:00:45 -0000 On 10/8/15 10:06 AM, Bernard Aboba wrote: > The IETF is committed to accessibility, so as to allow full > participation by individuals with disabilities. > > For the upcoming SLIM WG meeting (and for potential future virtual > meetings), we would like to understand if there are participants who > require accommodation (such as sign language interpretation). > > If you require accommodation, please send a note to myself and Natasha > (nrooney@gsma.com ), so that we can work with > you to make arrangements. At least for Yokahama remote participation will be challenging due to the time difference. (The slim session is at 3am EST.) Some of those interested will probably want to review after the meeting. Those who want to review the details can normally review the audio, or the full meetecho recording of the session. Will there be a transcript to make this available to the deaf? Thanks, Paul From nobody Tue Oct 13 13:16:27 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655F81A8A64 for ; Tue, 13 Oct 2015 13:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVTp6oyqilwi for ; Tue, 13 Oct 2015 13:16:24 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450: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 C743C1A8A87 for ; Tue, 13 Oct 2015 13:16:22 -0700 (PDT) Received: by wijq8 with SMTP id q8so49269293wij.0 for ; Tue, 13 Oct 2015 13:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Y5t/UGSGWw2mdlF+ZyIS7mzVz+vRGtFNAblDW5v1S2A=; b=pjvBrg+fn1sqcYUzPbb1Hmug1hoJJjObY6BWCdWiBToaMnvoP7kLyk6FZ+d3wfAJ8N bVaxdxdoST6Jr5bYK72ErVA4uXhTHVGc71TnH3dfuDvudTZ0eHEcni++lBUASdlplKFi h1ZM4WDSNwabV5NYyu+ATXJnDwVALtieVBzZWuXTANX+eWiY+gDEPbuqGB2jh72iP1wT eZjq1mmsJW96pMwzRYDgvgOeZmkvdpKwo24OAyJtGJXKDPKHSU4hdqUBA7gO3rNMHjjz dIQnrm7RsG+rX87l6Uz+HwKkQJA7zzx8RG/EI+7nXplCr+jN2jE9dDWzkieIft5C6bOz kwxg== X-Received: by 10.195.18.8 with SMTP id gi8mr17615752wjd.111.1444767381059; Tue, 13 Oct 2015 13:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.81 with HTTP; Tue, 13 Oct 2015 13:16:01 -0700 (PDT) From: Bernard Aboba Date: Tue, 13 Oct 2015 13:16:01 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a1130cc4688091c0522021e6a Archived-At: Subject: Re: [Slim] [slim] Barry's proposal to unblock the SLIM WG charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 20:16:25 -0000 --001a1130cc4688091c0522021e6a Content-Type: text/plain; charset=UTF-8 Barry said: "How does this work, appended to the charter (at the end)?: "Adding language information to the control streams will have security and privacy implications that must be understood and documented, as any protocol would have to do. Beyond that, this may open the door to inclusion of other information that could be more security- or privacy-sensitive than language preferences, and it could be important to have a close look at that early on. Therefore, this working group will include in its work a broader analysis of security and privacy implications of including such information in this manner. That analysis may be written as a separate document, or may be included in the working group's primary document(s). The Security Area will provide necessary ongoing participation for that analysis, and this requirement will not block progress on the working group's main work if such participation is not available." [BA] WFM. Security considerations need to be covered in the documents anyway, and adding privacy considerations shouldn't be overly burdensome, assuming that we have volunteers to do the work. --001a1130cc4688091c0522021e6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry said:=C2=A0

"How does this work, appende= d to the charter (at the end)?:
"Adding language information to the control streams will=
 have security
and privacy implications that must be understood and documented, as
any protocol would have to do.  Beyond that, this may open the door to
inclusion of other information that could be more security- or
privacy-sensitive than language preferences, and it could be important
to have a close look at that early on.  Therefore, this working group
will include in its work a broader analysis of security and privacy
implications of including such information in this manner.  That
analysis may be written as a separate document, or may be included in
the working group's primary document(s).  The Security Area will
provide necessary ongoing participation for that analysis, and this
requirement will not block progress on the working group's main work
if such participation is not available."

[BA] WFM.  Security considerations need to be covered in the documents anyw=
ay, and adding privacy considerations shouldn't be overly burdensome, a=
ssuming that we have volunteers to do the work.
--001a1130cc4688091c0522021e6a-- From nobody Tue Oct 13 17:53:59 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EC91ABD3B for ; Tue, 13 Oct 2015 17:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygb-lowF9TVx for ; Tue, 13 Oct 2015 17:53:57 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717AE1ABD37 for ; Tue, 13 Oct 2015 17:53:55 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-10v.sys.comcast.net with comcast id Uosb1r0032EPM3101otuda; Wed, 14 Oct 2015 00:53:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-07v.sys.comcast.net with comcast id Uott1r00N3Ge9ey01otugx; Wed, 14 Oct 2015 00:53:54 +0000 To: slim@ietf.org References: From: Paul Kyzivat Message-ID: <561DA7A1.7050505@alum.mit.edu> Date: Tue, 13 Oct 2015 20:53:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444784034; bh=BUlN0MuFlqYOGwCE8xjThFFxLjU4166qbCu/MHTXgnc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=oK6gjnJF+RGqcvcgN1KJKTsbXQwhIl9PZwkpJZyk/C0ssnMnubexiwtlnkoPTC6+L 7w5yOFvS/sAL/rc5tXbZvqTsONcvhUeYUWm4Il4IrMRr3vgDgObsnFzZSJVn2Ok1cC 9DqhG1yQ0s6shnUBS6l5q0FxHYqwRCAwvfJ0jhRw5tbcZpdCEZnm8M6josdYbwW7bm Kbr5eI3eWTZJRYMmny1HYTsYNVBHhVwLB5dnYbkx8eEJkhvnY8JD8ctbD5w40IAyTN OjxEhXDAhtRZcVA6SPdWcPuKphp3TwV0ks84KODxEH+0aFCsGAQvCQnotJvDFqTv3w rIahEYgPqfpKA== Archived-At: Subject: Re: [Slim] [slim] Barry's proposal to unblock the SLIM WG charter X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 00:53:59 -0000 The only problem I have with this is: who is going to do this work? The people interested in the other work of slim aren't necessarily interested or skilled for this work. Thanks, Paul On 10/13/15 4:16 PM, Bernard Aboba wrote: > Barry said: > > "How does this work, appended to the charter (at the end)?: > > "Adding language information to the control streams will have security > and privacy implications that must be understood and documented, as > any protocol would have to do. Beyond that, this may open the door to > inclusion of other information that could be more security- or > privacy-sensitive than language preferences, and it could be important > to have a close look at that early on. Therefore, this working group > will include in its work a broader analysis of security and privacy > implications of including such information in this manner. That > analysis may be written as a separate document, or may be included in > the working group's primary document(s). The Security Area will > provide necessary ongoing participation for that analysis, and this > requirement will not block progress on the working group's main work > if such participation is not available." > > [BA] WFM. Security considerations need to be covered in the documents anyway, and adding privacy considerations shouldn't be overly burdensome, assuming that we have volunteers to do the work. > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Thu Oct 15 09:15:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427761AC444 for ; Thu, 15 Oct 2015 09:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WIfhV2pwJA4 for ; Thu, 15 Oct 2015 09:15:06 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 1ABEF1AC43C for ; Thu, 15 Oct 2015 09:15:06 -0700 (PDT) Received: by qgez77 with SMTP id z77so75535182qge.1 for ; Thu, 15 Oct 2015 09:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=APWH9hUH8baynFiiq2GZpK1GzVjKZTEGoYSBtCGs4l8=; b=diUtkxBRATPsktiZn6UkAGQiuPVPnoUn/QSqcHrj/OdxrKnv39FvOmQbvyzox5u5t9 mgwxJYTfXWRXRVpNBeiQ2r5vZWnB1yA5nPDv6eu4gKNrIB/+Mu/DXdtuJojrJo1HxrqZ bu7lQFs2Y2z3iohf1awAM+JXE0cJuaarJp4R2hnnZVfg0h7pvJ6+EdoJahrjupu65gFh a3dRu+2TCo38+njEGh6YLiTjZhhKI82QFXVPbUsc+hWbPK1gxkVg/S9966pS+4inI/zQ xzy34Y3DLLOU5mikfxxla1B8m4VpyBzDOpC9R3oa20CRj5m0W5/aiqRUc+wSgRUVtDN5 YPVQ== MIME-Version: 1.0 X-Received: by 10.140.144.8 with SMTP id 8mr13275685qhq.54.1444925705294; Thu, 15 Oct 2015 09:15:05 -0700 (PDT) Received: by 10.233.222.133 with HTTP; Thu, 15 Oct 2015 09:15:05 -0700 (PDT) In-Reply-To: <20151015160544.17995.87517.idtracker@ietfa.amsl.com> References: <20151015160544.17995.87517.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 17:15:05 +0100 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a11353d7c6417a4052226fb52 Archived-At: Subject: [Slim] Fwd: New Version Notification for draft-tomkinson-slim-multilangcontent-02.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:15:09 -0000 --001a11353d7c6417a4052226fb52 Content-Type: text/plain; charset=UTF-8 Hi All, I have just submitted a new version of the email I-D for multilingual email. The details are below. I would like to get together a group of people who are interested in testing the behaviour of current mail agents when receiving multilingual email and also some people that would like to start coding prototype implementations of mail agents that can write and read multilingual emails correctly. This is to see if the I-D needs amending based on this testing before it is submitted to the IESG. Please make yourself known if you want to be included in this test group and specify whether you are interested in backwards compatibility testing, prototype development or both. Nik. ------------ A new version of I-D, draft-tomkinson-slim-multilangcontent-02.txt has been successfully submitted by Nik Tomkinson and posted to the IETF repository. Name: draft-tomkinson-slim-multilangcontent Revision: 02 Title: Multiple Language Content Type Document date: 2015-10-15 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-tomkinson-slim-multilangcontent-02.txt Status: https://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ Htmlized: https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-tomkinson-slim-multilangcontent-02 Abstract: This document defines an addition to the Multipurpose Internet Mail Extensions (MIME) standard to make it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language code and selected by the email client based on a user's language settings or locale. The IETF Secretariat -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a11353d7c6417a4052226fb52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi A= ll,

I = have just submitted a new version of the email I-D for multilingual email. = The details are below.=C2=A0

I would like to get together a group of people who a= re interested in testing the behaviour of current mail agents when receivin= g multilingual email and also some people that would like to start coding p= rototype implementations of mail agents that can write and read multilingua= l emails correctly. This is to see if the I-D needs amending based on this = testing before it is submitted to the IESG.

Please make yourself known if you wan= t to be included in this test group and specify whether you are interested = in backwards compatibility testing, prototype development or both.


Nik.
------------


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

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tomkinson-slim-multilan= gcontent
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multiple Language Content Type
Document date:=C2=A0 2015-10-15
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-tomki= nson-slim-multilangcontent-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-tomkinson-slim-multilang= content/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-tomkinson-slim-multilangcontent-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-tomkinson-s= lim-multilangcontent-02

Abstract:
=C2=A0 =C2=A0This document defines an addition to the Multipurpose Internet= Mail
=C2=A0 =C2=A0Extensions (MIME) standard to make it possible to send one mes= sage
=C2=A0 =C2=A0that contains multiple language versions of the same informati= on.
=C2=A0 =C2=A0The translations would be identified by a language code and se= lected
=C2=A0 =C2=A0by the email client based on a user's language settings or= locale.



The IETF Secretariat




-- 
------------------=
-----------------------------------------------
Multiple Language Conten=
t Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
----=
-------------------------------------------------------------
--001a11353d7c6417a4052226fb52-- From nobody Fri Oct 16 09:53:38 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C166F1A6F9E; Fri, 16 Oct 2015 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi2jcNtHs8jM; Fri, 16 Oct 2015 09:53:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 647041B2C00; Fri, 16 Oct 2015 09:53:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016165330.12818.19572.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 09:53:30 -0700 Archived-At: Cc: slim@ietf.org, The IESG , slim-chairs@ietf.org Subject: [Slim] WG Action: Formed Selection of Language for Internet Media (slim) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 16:53:36 -0000 A new IETF working group has been formed in the Applications and Real-Time Area. For additional information please contact the Area Directors or the WG Chairs. Selection of Language for Internet Media (slim) ------------------------------------------------ Current Status: Proposed WG Chairs: Bernard Aboba N Rooney Assigned Area Director: Barry Leiba Mailing list Address: slim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/slim Archive: https://mailarchive.ietf.org/arch/browse/slim/ Charter: A mutually comprehensible language is helpful for human communication. This is true across a range of circumstances and environments. In general, the problem is most acute in situations where there is not a clear choice for a single language, such as environments lacking contextual or out-of-band information regarding the identity of the parties and the language to be used. The group will address two specific cases that most urgently need a technical solution: One problem space is non-real-time communication, specifically email for one-to-many or where the set of recipients is dynamic or different recipients require different languages; the other is real-time communication, specifically emergency calling, preferably also useful for other cases where the parties may not know each other personally or where one party wishes to accommodate people with varying language and media needs. In the real-time communication case, language and media are intrinsically linked, for example, signed languages require a video media. While the two use cases are in different contexts (real time and non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation. Some of the details will also be in common across the cases, e.g., the language tags. Having a single WG address both cases makes it clear that these are two aspects of the same basic problem. A single WG also makes it easier to maximize similarities and avoid unnecessary fragmentation of the solutions and facilitates broader review. The group will start by producing specifications for email and for real-time communications. In the email case, the group will determine a MIME based solution (based on draft-tomkinson-slim-multilangcontent) that enables a single email message to contain multiple language versions of the content, with provisions to help clients select a best-fit version. In the real-time communication case, the group will produce a specification (based on draft-gellens-slim-negotiating-human-language) enabling negotiation of a human language per media stream. The specification must be suitable for use in emergency communications as specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate media); it is desirable to also be suitable for use in non-emergency real-time communications that share the same call set-up and media negotiation protocols. The mechanism will permit the caller's media and language needs and preferences to be matched against what the called party is able to provide. Alternatives such as doing the media negotiation in SIP have been explored in the past and are out of scope (although SIP-based mechanisms may be introduced when routing considerations are addressed). The group's initial focus will not be on supporting language-based call routing decisions. Once the initial work is sufficiently progressed, the group may address call routing, with the timing at the judgment of the chairs. Recognizing that complex solutions are significantly less likely to see widespread deployment, the group will solve the most common use cases and avoid adding complexity to solve edge or less-common cases. By adding language to the existing media negotiation mechanism as used in RFC 6443 and RFC 6881, the group can meet the basic use cases with minimal added complexity and be able to enhance later for additional use cases as needed. Milestones: Nov 2015 - Submit "Multiple Language Content Type" to the IESG (based on draft-tomkinson-slim-multilangcontent) Mar 2016 - Submit "Negotiating Human Language in Real-Time Communications" to the IESG (based on draft-gellens-slim-negotiating-human-language) From nobody Mon Oct 19 02:50:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4E91A8843 for ; Mon, 19 Oct 2015 02:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2GRZMZkZdui for ; Mon, 19 Oct 2015 02:50:22 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::611]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A011A87D7 for ; Mon, 19 Oct 2015 02:50:21 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (10.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 09:50:13 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 09:50:13 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Formed Selection of Language for Internet Media (slim) Thread-Index: AQHRClOMKEuhbFVqlEuwWHJLzAsxrA== Date: Mon, 19 Oct 2015 09:50:13 +0000 Message-ID: References: <2C578AC9-3295-4FFA-9A06-A21B86297178@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [118.109.86.198] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 5:fkPfsFjlovO+ExkVRTrMd9GRnEuOp5G1xOCY6+L7xgFro+heu1I86Y6N7Z7NwIUQeYbo4vdbh+GfFsX6pWDrba9nvcKW1F0P/TsP7T6eYrkobMZI432NKm0zToZ0fOdBEnypAFSQ7cYzPrDjh+eD4g==; 24:elFipMZnFyNeviQL2pG2pLdykvxbBl2lkwqe+g9PkOZEnLBxtdEGNy1rdoKr/1NOhTJCiwQ9chV9KntWoN4pwBzWMwyjRyxvh5ZQqXd5w3A=; 20:0Fra8HREbPc1c52Klc/fCLNNMR6/JQMQIFrbj0D+bLqrq3cffpEozmk2+2+e2xy+bCy/ZPdksFGN1Y+Av+CyGw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(194151415913766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(53754006)(45074003)(377454003)(199003)(189998001)(5002640100001)(15975445007)(82746002)(106356001)(2900100001)(40100003)(77096005)(87936001)(122556002)(83716003)(16236675004)(5007970100001)(105586002)(66066001)(106116001)(2351001)(229853001)(19617315012)(64706001)(5004730100002)(110136002)(46102003)(33656002)(102836002)(50226001)(101416001)(2501003)(50986999)(5890100001)(76176999)(11100500001)(86362001)(97736004)(57306001)(92566002)(81156007)(5001960100002)(36756003)(19580395003)(5001920100001)(450100001)(5008740100001)(10400500002)(107886002)(19580405001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2CB771D870D478596612AD29EA2E56Fgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 09:50:13.1888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 118.109.86.198 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Formed Selection of Language for Internet Media (slim) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 09:50:29 -0000 --_000_D2CB771D870D478596612AD29EA2E56Fgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpUaGFuay15b3UgZm9yIHN1YnNjcmliaW5nIHRvIHRoZSBTTElNIG1haWxpbmcg bGlzdC4gSSBoYXZlIHNvbWUgbmV3cyBmb3IgZXZlcnlvbmUgd2hpY2ggaG9wZWZ1bGx5IHdvbuKA mXQgYmUgdG9vIG11Y2ggb2YgYSBzdXJwcmlzZSENCg0KQ2hhcnRlcg0KVGhlIFNMSU0gY2hhcnRl ciBoYXMgYmVlbiBhcHByb3ZlZCwgc28gd2UgYXJlIG5vdyBvZmZpY2lhbGx5IGFuIElFVEYgV29y a2luZyBHcm91cCEgVGhhbmsteW91IHRvIGV2ZXJ5b25lIHdobyBnYXZlIGlucHV0IHRvIHRoaXMu IFlvdSBjYW4gcmVhZCB0aGUgZnVsbCBjaGFydGVyIG9uIGRhdGF0cmFja2VyIChhbGwgbGlua3Mg YXJlIGJlbG93KS4NCg0KQ2hhaXJzDQpBcyB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gc2VlIGZyb20g dGhlIGFib3ZlIGxpbmsgd2UgaGF2ZSB0d28gY2hhaXJzLCBCZXJuYXJkIEFib2JhIGFuZCBteXNl bGYsIE5hdGFzaGEgUm9vbmV5LiBCZXJuYXJkIGlzIGEgZmFtb3VzIElFVEZlciBhbmQgbWFueSBv ZiB5b3Ugd2lsbCBrbm93IGhpbSBhcyBhIFByaW5jaXBsZSBBcmNoaXRlY3QgYXQgTWljcm9zb2Z0 LCBhIHByZXZpb3VzIElBQiBDaGFpciwgYSBXM0MgV2ViUlRDIGRyYWZ0IGVkaXRvciBhbmQgYSBj b250cmlidXRvciB0byBhcm91bmQgNjAgUkZDcy4gSSB3b3JrIGZvciBHU01BLCBhIGdsb2JhbCB0 ZWxlY29tbXVuaWNhdGlvbnMgYXNzb2NpYXRpb24sIGFzIGEgd2ViIGFuZCBpbnRlcm5ldCB0ZWNo bm9sb2dpc3Qgd29ya2luZyBvbiBjb25uZWN0aW5nIGludGVybmV0IHRlY2hub2xvZ2llcyB3aXRo IHRoZSBtb2JpbGUgbmV0d29yay4NCg0KQXMgY2hhaXJzIG9mIHRoZSB3b3JraW5nIGdyb3VwIEJl cm5hcmQgYW5kIEkgd2lsbCB3b3JrIHRvIHN1cHBvcnQgdGhlIGJ1aWxkaW5nIG9mIG91ciBkcmFm dHMsIG9yZ2FuaXNpbmcgb3VyIG1lZXRpbmdzLCBtYW5hZ2luZyBvdXIgbWFpbGluZyBsaXN0cyBh bmQgbWFraW5nIHN1cmUgd2Ugd29yayB3aXRoIHRoZSBJRVRGIHByb2Nlc3MgdG8gdHVybiBvdXIg ZHJhZnRzIGludG8gUkZDcyBpbiBhIHRpbWVseSBtYW5uZXIuDQoNClF1ZXN0aW9ucw0KSWYgeW91 IGhhdmUgcXVlc3Rpb25zIHBsZWFzZSBkbyBhc2sgdXMuIFBvc3RpbmcgcXVlc3Rpb25zIHRvIHRo ZSBsaXN0IGlzIHByZWZlcnJlZCwgYnV0IHlvdSBjYW4gYWxzbyBlbWFpbCB1cyBkaXJlY3RseSBp ZiB5b3UgbmVlZCB0by4NCg0KV2XigJlyZSBsb29raW5nIGZvcndhcmQgdG8gd29ya2luZyB3aXRo IHlvdSBhbGwhDQoNCk5hdGFzaGENCg0KTGlua3MNCkRhdGF0cmFja2VyIFBhZ2UNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9jaGFydGVyLw0KTWFpbCBBcmNoaXZlDQpodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NsaW0vDQpJRVRGOTQNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTQvDQpJRVRGOTQgQWdlbmRhDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTQvYWdlbmRhLmh0bWwNCg0KDQoNCk5hdGFzaGEgUm9v bmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJiBJRVRGIHwgR1NNQSB8 IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMw IDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpu cm9vbmV5QGdzbS5vcmc+DQpUb2t5bywgSmFwYW4NCg0KDQpGcm9tOiBUaGUgSUVTRyA8aWVzZy1z ZWNyZXRhcnlAaWV0Zi5vcmc8bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPj4NCkRhdGU6 IE9jdG9iZXIgMTYsIDIwMTUgYXQgOTo1MzozMCBBTSBQRFQNClRvOiAiSUVURi1Bbm5vdW5jZSIg PGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0K Q2M6IHNsaW1AaWV0Zi5vcmc8bWFpbHRvOnNsaW1AaWV0Zi5vcmc+LCBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+LCBzbGltLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86c2xpbS1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbU2xpbV0gV0cgQWN0aW9uOiBGb3Jt ZWQgU2VsZWN0aW9uIG9mIExhbmd1YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSkNCg0KQSBu ZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGZvcm1lZCBpbiB0aGUgQXBwbGljYXRpb25z IGFuZA0KUmVhbC1UaW1lIEFyZWEuIEZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHBsZWFzZSBj b250YWN0IHRoZSBBcmVhDQpEaXJlY3RvcnMgb3IgdGhlIFdHIENoYWlycy4NCg0KU2VsZWN0aW9u IG9mIExhbmd1YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSkNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ3VycmVudCBTdGF0dXM6IFByb3Bvc2Vk IFdHDQoNCkNoYWlyczoNCiBCZXJuYXJkIEFib2JhIDxCZXJuYXJkX0Fib2JhQGhvdG1haWwuY29t PG1haWx0bzpCZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tPj4NCiBOIFJvb25leSA8bnJvb25leUBn c21hLmNvbTxtYWlsdG86bnJvb25leUBnc21hLmNvbT4+DQoNCkFzc2lnbmVkIEFyZWEgRGlyZWN0 b3I6DQogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPG1haWx0bzpiYXJyeWxl aWJhQGNvbXB1dGVyLm9yZz4+DQoNCk1haWxpbmcgbGlzdA0KIEFkZHJlc3M6IHNsaW1AaWV0Zi5v cmc8bWFpbHRvOnNsaW1AaWV0Zi5vcmc+DQogVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0NCiBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvYnJvd3NlL3NsaW0vDQoNCkNoYXJ0ZXI6DQoNCkEgbXV0dWFsbHkgY29t cHJlaGVuc2libGUgbGFuZ3VhZ2UgaXMgaGVscGZ1bCBmb3IgaHVtYW4gY29tbXVuaWNhdGlvbi4N ClRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2VzIGFuZCBlbnZpcm9u bWVudHMuICBJbg0KZ2VuZXJhbCwgdGhlIHByb2JsZW0gaXMgbW9zdCBhY3V0ZSBpbiBzaXR1YXRp b25zIHdoZXJlIHRoZXJlIGlzIG5vdCBhDQpjbGVhciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1 YWdlLCBzdWNoIGFzIGVudmlyb25tZW50cyBsYWNraW5nDQpjb250ZXh0dWFsIG9yIG91dC1vZi1i YW5kIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgaWRlbnRpdHkgb2YgdGhlDQpwYXJ0aWVzIGFu ZCB0aGUgbGFuZ3VhZ2UgdG8gYmUgdXNlZC4NCg0KVGhlIGdyb3VwIHdpbGwgYWRkcmVzcyB0d28g c3BlY2lmaWMgY2FzZXMgdGhhdCBtb3N0IHVyZ2VudGx5IG5lZWQgYQ0KdGVjaG5pY2FsIHNvbHV0 aW9uOiBPbmUgcHJvYmxlbSBzcGFjZSBpcyBub24tcmVhbC10aW1lIGNvbW11bmljYXRpb24sDQpz cGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10by1tYW55IG9yIHdoZXJlIHRoZSBzZXQgb2YgcmVj aXBpZW50cyBpcw0KZHluYW1pYyBvciBkaWZmZXJlbnQgcmVjaXBpZW50cyByZXF1aXJlIGRpZmZl cmVudCBsYW5ndWFnZXM7IHRoZSBvdGhlcg0KaXMgcmVhbC10aW1lIGNvbW11bmljYXRpb24sIHNw ZWNpZmljYWxseSBlbWVyZ2VuY3kgY2FsbGluZywgcHJlZmVyYWJseQ0KYWxzbyB1c2VmdWwgZm9y IG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25vdyBlYWNoIG90aGVyDQpw ZXJzb25hbGx5IG9yIHdoZXJlIG9uZSBwYXJ0eSB3aXNoZXMgdG8gYWNjb21tb2RhdGUgcGVvcGxl IHdpdGggdmFyeWluZw0KbGFuZ3VhZ2UgYW5kIG1lZGlhIG5lZWRzLg0KDQpJbiB0aGUgcmVhbC10 aW1lIGNvbW11bmljYXRpb24gY2FzZSwgbGFuZ3VhZ2UgYW5kIG1lZGlhIGFyZQ0KaW50cmluc2lj YWxseSBsaW5rZWQsIGZvciBleGFtcGxlLCBzaWduZWQgbGFuZ3VhZ2VzIHJlcXVpcmUgYSB2aWRl bw0KbWVkaWEuDQoNCldoaWxlIHRoZSB0d28gdXNlIGNhc2VzIGFyZSBpbiBkaWZmZXJlbnQgY29u dGV4dHMgKHJlYWwgdGltZSBhbmQNCm5vbi1yZWFsLXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29h bCBpcyB0aGUgc2FtZTogdG8gZW5hYmxlIHNlbGVjdGlvbiBvZg0KdGhlIGJlc3QtZml0IGxhbmd1 YWdlKHMpIGZvciBhIHNwZWNpZmljIHNpdHVhdGlvbi4gIFNvbWUgb2YgdGhlIGRldGFpbHMNCndp bGwgYWxzbyBiZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5nLiwgdGhlIGxhbmd1YWdl IHRhZ3MuDQpIYXZpbmcgYSBzaW5nbGUgV0cgYWRkcmVzcyBib3RoIGNhc2VzIG1ha2VzIGl0IGNs ZWFyIHRoYXQgdGhlc2UgYXJlIHR3bw0KYXNwZWN0cyBvZiB0aGUgc2FtZSBiYXNpYyBwcm9ibGVt LiAgQSBzaW5nbGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG8NCm1heGltaXplIHNpbWlsYXJp dGllcyBhbmQgYXZvaWQgdW5uZWNlc3NhcnkgZnJhZ21lbnRhdGlvbiBvZiB0aGUNCnNvbHV0aW9u cyBhbmQgZmFjaWxpdGF0ZXMgYnJvYWRlciByZXZpZXcuDQoNClRoZSBncm91cCB3aWxsIHN0YXJ0 IGJ5IHByb2R1Y2luZyBzcGVjaWZpY2F0aW9ucyBmb3IgZW1haWwgYW5kIGZvcg0KcmVhbC10aW1l IGNvbW11bmljYXRpb25zLg0KDQpJbiB0aGUgZW1haWwgY2FzZSwgdGhlIGdyb3VwIHdpbGwgZGV0 ZXJtaW5lIGEgTUlNRSBiYXNlZCBzb2x1dGlvbiAoYmFzZWQNCm9uIGRyYWZ0LXRvbWtpbnNvbi1z bGltLW11bHRpbGFuZ2NvbnRlbnQpIHRoYXQgZW5hYmxlcyBhIHNpbmdsZSBlbWFpbA0KbWVzc2Fn ZSB0byBjb250YWluIG11bHRpcGxlIGxhbmd1YWdlIHZlcnNpb25zIG9mIHRoZSBjb250ZW50LCB3 aXRoDQpwcm92aXNpb25zIHRvIGhlbHAgY2xpZW50cyBzZWxlY3QgYSBiZXN0LWZpdCB2ZXJzaW9u Lg0KDQpJbiB0aGUgcmVhbC10aW1lIGNvbW11bmljYXRpb24gY2FzZSwgdGhlIGdyb3VwIHdpbGwg cHJvZHVjZSBhDQpzcGVjaWZpY2F0aW9uIChiYXNlZCBvbiBkcmFmdC1nZWxsZW5zLXNsaW0tbmVn b3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UpDQplbmFibGluZyBuZWdvdGlhdGlvbiBvZiBhIGh1bWFu IGxhbmd1YWdlIHBlciBtZWRpYSBzdHJlYW0uICBUaGUNCnNwZWNpZmljYXRpb24gbXVzdCBiZSBz dWl0YWJsZSBmb3IgdXNlIGluIGVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucyBhcw0Kc3BlY2lmaWVk IGluIFJGQyA2NDQzIGFuZCBSRkMgNjg4MSAod2hpY2ggdXNlIFNJUCBhbmQgU0RQIHRvIG5lZ290 aWF0ZQ0KbWVkaWEpOyBpdCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBmb3IgdXNl IGluIG5vbi1lbWVyZ2VuY3kNCnJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyB0aGF0IHNoYXJlIHRo ZSBzYW1lIGNhbGwgc2V0LXVwIGFuZCBtZWRpYQ0KbmVnb3RpYXRpb24gcHJvdG9jb2xzLiAgVGhl IG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3MgbWVkaWEgYW5kDQpsYW5ndWFnZSBu ZWVkcyBhbmQgcHJlZmVyZW5jZXMgdG8gYmUgbWF0Y2hlZCBhZ2FpbnN0IHdoYXQgdGhlIGNhbGxl ZA0KcGFydHkgaXMgYWJsZSB0byBwcm92aWRlLiAgQWx0ZXJuYXRpdmVzIHN1Y2ggYXMgZG9pbmcg dGhlIG1lZGlhDQpuZWdvdGlhdGlvbiBpbiBTSVAgaGF2ZSBiZWVuIGV4cGxvcmVkIGluIHRoZSBw YXN0IGFuZCBhcmUgb3V0IG9mIHNjb3BlDQooYWx0aG91Z2ggU0lQLWJhc2VkIG1lY2hhbmlzbXMg bWF5IGJlIGludHJvZHVjZWQgd2hlbiByb3V0aW5nDQpjb25zaWRlcmF0aW9ucyBhcmUgYWRkcmVz c2VkKS4NCg0KVGhlIGdyb3VwJ3MgaW5pdGlhbCBmb2N1cyB3aWxsIG5vdCBiZSBvbiBzdXBwb3J0 aW5nIGxhbmd1YWdlLWJhc2VkIGNhbGwNCnJvdXRpbmcgZGVjaXNpb25zLiAgT25jZSB0aGUgaW5p dGlhbCB3b3JrIGlzIHN1ZmZpY2llbnRseSBwcm9ncmVzc2VkLCB0aGUNCmdyb3VwIG1heSAgYWRk cmVzcyBjYWxsIHJvdXRpbmcsIHdpdGggdGhlIHRpbWluZyBhdCB0aGUganVkZ21lbnQgb2YgdGhl DQpjaGFpcnMuDQoNClJlY29nbml6aW5nIHRoYXQgY29tcGxleCBzb2x1dGlvbnMgYXJlIHNpZ25p ZmljYW50bHkgbGVzcw0KbGlrZWx5IHRvIHNlZSB3aWRlc3ByZWFkIGRlcGxveW1lbnQsIHRoZSBn cm91cCB3aWxsIHNvbHZlIHRoZSBtb3N0DQpjb21tb24gdXNlIGNhc2VzIGFuZCBhdm9pZCBhZGRp bmcgY29tcGxleGl0eSB0byBzb2x2ZSBlZGdlIG9yDQpsZXNzLWNvbW1vbiBjYXNlcy4NCg0KQnkg YWRkaW5nIGxhbmd1YWdlIHRvIHRoZSBleGlzdGluZyBtZWRpYSBuZWdvdGlhdGlvbiBtZWNoYW5p c20gYXMgdXNlZA0KaW4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0aGUgZ3JvdXAgY2FuIG1lZXQg dGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQptaW5pbWFsIGFkZGVkIGNvbXBsZXhpdHkgYW5kIGJl IGFibGUgdG8gZW5oYW5jZSBsYXRlciBmb3IgYWRkaXRpb25hbCB1c2UNCmNhc2VzIGFzIG5lZWRl ZC4NCg0KTWlsZXN0b25lczoNCiBOb3YgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUgTGFuZ3VhZ2Ug Q29udGVudCBUeXBlIiB0byB0aGUgSUVTRyAoYmFzZWQNCm9uIGRyYWZ0LXRvbWtpbnNvbi1zbGlt LW11bHRpbGFuZ2NvbnRlbnQpDQogTWFyIDIwMTYgLSBTdWJtaXQgIk5lZ290aWF0aW5nIEh1bWFu IExhbmd1YWdlIGluIFJlYWwtVGltZQ0KQ29tbXVuaWNhdGlvbnMiIHRvIHRoZSBJRVNHIChiYXNl ZCBvbg0KZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlKQ0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTTElNIG1h aWxpbmcgbGlzdA0KU0xJTUBpZXRmLm9yZzxtYWlsdG86U0xJTUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbQ0KDQoNClRoaXMgZW1haWwgYW5kIGl0 cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBt YXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91 IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Ig c2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAr NDQgMjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K --_000_D2CB771D870D478596612AD29EA2E56Fgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVk aXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+SGkgYWxsIQ0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhhbmsteW91IGZvciBzdWJzY3JpYmluZyB0byB0aGUgU0xJTSBtYWls aW5nIGxpc3QuIEkgaGF2ZSBzb21lIG5ld3MgZm9yIGV2ZXJ5b25lIHdoaWNoIGhvcGVmdWxseSB3 b27igJl0IGJlIHRvbyBtdWNoIG9mIGEgc3VycHJpc2UhDQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2I+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjx1IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkNoYXJ0ZXI8L2I+PC91PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGUgU0xJTSBjaGFydGVyIGhhcyBiZWVuIGFwcHJvdmVkLCBzbyB3ZSBhcmUgbm93 IG9mZmljaWFsbHkgYW4gSUVURiBXb3JraW5nIEdyb3VwISBUaGFuay15b3UgdG8gZXZlcnlvbmUg d2hvIGdhdmUgaW5wdXQgdG8gdGhpcy4gWW91IGNhbiByZWFkIHRoZSBmdWxsIGNoYXJ0ZXIgb24g ZGF0YXRyYWNrZXIgKGFsbCBsaW5rcyBhcmUgYmVsb3cpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHUgY2xhc3M9IiI+PGIgY2xhc3M9 IiI+Q2hhaXJzPC9iPjwvdT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgeW91IHNob3VsZCBiZSBh YmxlIHRvIHNlZSBmcm9tIHRoZSBhYm92ZSBsaW5rIHdlIGhhdmUgdHdvIGNoYWlycywgQmVybmFy ZCBBYm9iYSBhbmQgbXlzZWxmLCBOYXRhc2hhIFJvb25leS4gQmVybmFyZCBpcyBhIGZhbW91cyBJ RVRGZXIgYW5kIG1hbnkgb2YgeW91IHdpbGwga25vdyBoaW0gYXMgYSBQcmluY2lwbGUgQXJjaGl0 ZWN0IGF0IE1pY3Jvc29mdCwgYSBwcmV2aW91cyBJQUIgQ2hhaXIsIGEgVzNDIFdlYlJUQyBkcmFm dA0KIGVkaXRvciBhbmQgYSZuYnNwO2NvbnRyaWJ1dG9yIHRvIGFyb3VuZCA2MCBSRkNzLiBJIHdv cmsgZm9yIEdTTUEsIGEgZ2xvYmFsIHRlbGVjb21tdW5pY2F0aW9ucyBhc3NvY2lhdGlvbiwgYXMg YSB3ZWIgYW5kIGludGVybmV0IHRlY2hub2xvZ2lzdCB3b3JraW5nIG9uIGNvbm5lY3RpbmcgaW50 ZXJuZXQgdGVjaG5vbG9naWVzIHdpdGggdGhlIG1vYmlsZSBuZXR3b3JrLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgY2hh aXJzIG9mIHRoZSB3b3JraW5nIGdyb3VwIEJlcm5hcmQgYW5kIEkgd2lsbCB3b3JrIHRvIHN1cHBv cnQgdGhlIGJ1aWxkaW5nIG9mIG91ciBkcmFmdHMsIG9yZ2FuaXNpbmcgb3VyIG1lZXRpbmdzLCBt YW5hZ2luZyBvdXIgbWFpbGluZyBsaXN0cyBhbmQgbWFraW5nIHN1cmUgd2Ugd29yayB3aXRoIHRo ZSBJRVRGIHByb2Nlc3MgdG8gdHVybiBvdXIgZHJhZnRzIGludG8gUkZDcyBpbiBhIHRpbWVseSBt YW5uZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48dSBjbGFzcz0iIj48YiBjbGFzcz0iIj5RdWVzdGlvbnM8L2I+PC91PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JZiB5b3UgaGF2ZSBxdWVzdGlvbnMgcGxlYXNlIGRvIGFzayB1cy4gUG9z dGluZyBxdWVzdGlvbnMgdG8gdGhlIGxpc3QgaXMgcHJlZmVycmVkLCBidXQgeW91IGNhbiBhbHNv IGVtYWlsIHVzIGRpcmVjdGx5IGlmIHlvdSBuZWVkIHRvLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2XigJlyZSBsb29raW5nIGZvcndh cmQgdG8gd29ya2luZyB3aXRoIHlvdSBhbGwhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5OYXRhc2hhPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj48dSBjbGFz cz0iIj5MaW5rczwvdT48L2I+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5EYXRhdHJhY2tlciBQYWdlPC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hhcnRlci8iIGNsYXNz PSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9jaGFydGVyLzwvYT48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+TWFpbCBBcmNoaXZlPC9iPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv d3NlL3NsaW0vIiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv d3NlL3NsaW0vPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5JRVRGOTQ8L2I+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21lZXRp bmcvOTQvIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzk0LzwvYT48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SUVURjk0IEFnZW5k YTwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzk0L2FnZW5kYS5odG1sIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvOTQvYWdlbmRhLmh0bWw8L2E+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9n aXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhy ZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208 L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lw ZTombmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5 QGdzbS5vcmc8L2E+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0 byIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZy b206PC9iPiBUaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYu b3JnIiBjbGFzcz0iIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+RGF0ZTo8L2I+IE9jdG9iZXIgMTYsIDIwMTUgYXQgOTo1MzozMCBBTSBQ RFQ8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+ICZxdW90O0lFVEYtQW5ub3VuY2Um cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIiBjbGFzcz0i Ij5pZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzbGltQGlldGYub3JnIiBjbGFzcz0iIj5zbGltQGll dGYub3JnPC9hPiwgVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiBj bGFzcz0iIj5pZXNnQGlldGYub3JnPC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86c2xpbS1jaGFp cnNAaWV0Zi5vcmciIGNsYXNzPSIiPnNsaW0tY2hhaXJzQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPiA8YiBjbGFzcz0iIj5bU2xpbV0gV0cgQWN0aW9u OiBGb3JtZWQgU2VsZWN0aW9uIG9mIExhbmd1YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSk8 L2I+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IiI+QSBuZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGZvcm1lZCBpbiB0aGUgQXBw bGljYXRpb25zIGFuZDwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5SZWFsLVRp bWUgQXJlYS4gRm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcGxlYXNlIGNvbnRhY3QgdGhlIEFy ZWE8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+RGlyZWN0b3JzIG9yIHRoZSBX RyBDaGFpcnMuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5TZWxlY3Rpb24gb2YgTGFuZ3VhZ2UgZm9yIEludGVy bmV0IE1lZGlhIChzbGltKTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIGNs YXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Q3VycmVudCBTdGF0dXM6IFByb3Bvc2VkIFdHPC9zcGFu PjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3Bh biBjbGFzcz0iIj5DaGFpcnM6PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPiZu YnNwO0Jlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpCZXJuYXJkX0Fib2JhQGhvdG1h aWwuY29tIiBjbGFzcz0iIj5CZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tPC9hPiZndDs8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Jm5ic3A7TiBSb29uZXkgJmx0OzxhIGhyZWY9 Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj5ucm9vbmV5QGdzbWEuY29tPC9hPiZn dDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPkFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6PC9zcGFuPjxiciBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSIiPiZuYnNwO0JhcnJ5IExlaWJhICZsdDs8YSBocmVmPSJtYWls dG86YmFycnlsZWliYUBjb21wdXRlci5vcmciIGNsYXNzPSIiPmJhcnJ5bGVpYmFAY29tcHV0ZXIu b3JnPC9hPiZndDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPk1haWxpbmcgbGlzdDwvc3Bhbj48YnIgY2xhc3M9 IiI+DQo8c3BhbiBjbGFzcz0iIj4mbmJzcDtBZGRyZXNzOiA8YSBocmVmPSJtYWlsdG86c2xpbUBp ZXRmLm9yZyIgY2xhc3M9IiI+c2xpbUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+Jm5ic3A7VG8gU3Vic2NyaWJlOiA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0iIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3Bh biBjbGFzcz0iIj4mbmJzcDtBcmNoaXZlOiA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvYnJvd3NlL3NsaW0vIiBjbGFzcz0iIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9icm93c2Uvc2xpbS88L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5DaGFydGVyOjwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+QSBtdXR1YWxseSBjb21wcmVoZW5zaWJsZSBsYW5ndWFnZSBpcyBoZWxw ZnVsIGZvciBodW1hbiBjb21tdW5pY2F0aW9uLg0KPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IGNsYXNzPSIiPlRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2VzIGFu ZCBlbnZpcm9ubWVudHMuICZuYnNwO0luPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNz PSIiPmdlbmVyYWwsIHRoZSBwcm9ibGVtIGlzIG1vc3QgYWN1dGUgaW4gc2l0dWF0aW9ucyB3aGVy ZSB0aGVyZSBpcyBub3QgYTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5jbGVh ciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1YWdlLCBzdWNoIGFzIGVudmlyb25tZW50cyBsYWNr aW5nPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmNvbnRleHR1YWwgb3Igb3V0 LW9mLWJhbmQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSBpZGVudGl0eSBvZiB0aGU8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+cGFydGllcyBhbmQgdGhlIGxhbmd1YWdlIHRv IGJlIHVzZWQuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5UaGUgZ3JvdXAgd2lsbCBhZGRyZXNzIHR3byBzcGVj aWZpYyBjYXNlcyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBhPC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPnRlY2huaWNhbCBzb2x1dGlvbjogT25lIHByb2JsZW0gc3BhY2UgaXMg bm9uLXJlYWwtdGltZSBjb21tdW5pY2F0aW9uLDwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBj bGFzcz0iIj5zcGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10by1tYW55IG9yIHdoZXJlIHRoZSBz ZXQgb2YgcmVjaXBpZW50cyBpczwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5k eW5hbWljIG9yIGRpZmZlcmVudCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdl czsgdGhlIG90aGVyPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmlzIHJlYWwt dGltZSBjb21tdW5pY2F0aW9uLCBzcGVjaWZpY2FsbHkgZW1lcmdlbmN5IGNhbGxpbmcsIHByZWZl cmFibHk8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+YWxzbyB1c2VmdWwgZm9y IG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25vdyBlYWNoIG90aGVyPC9z cGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnBlcnNvbmFsbHkgb3Igd2hlcmUgb25l IHBhcnR5IHdpc2hlcyB0byBhY2NvbW1vZGF0ZSBwZW9wbGUgd2l0aCB2YXJ5aW5nPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmxhbmd1YWdlIGFuZCBtZWRpYSBuZWVkcy48L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxz cGFuIGNsYXNzPSIiPkluIHRoZSByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiBjYXNlLCBsYW5ndWFn ZSBhbmQgbWVkaWEgYXJlPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmludHJp bnNpY2FsbHkgbGlua2VkLCBmb3IgZXhhbXBsZSwgc2lnbmVkIGxhbmd1YWdlcyByZXF1aXJlIGEg dmlkZW88L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWVkaWEuPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBj bGFzcz0iIj5XaGlsZSB0aGUgdHdvIHVzZSBjYXNlcyBhcmUgaW4gZGlmZmVyZW50IGNvbnRleHRz IChyZWFsIHRpbWUgYW5kPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPm5vbi1y ZWFsLXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29hbCBpcyB0aGUgc2FtZTogdG8gZW5hYmxlIHNl bGVjdGlvbiBvZjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj50aGUgYmVzdC1m aXQgbGFuZ3VhZ2UocykgZm9yIGEgc3BlY2lmaWMgc2l0dWF0aW9uLiAmbmJzcDtTb21lIG9mIHRo ZSBkZXRhaWxzPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPndpbGwgYWxzbyBi ZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5nLiwgdGhlIGxhbmd1YWdlIHRhZ3MuIDwv c3Bhbj4NCjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPkhhdmluZyBhIHNpbmdsZSBXRyBh ZGRyZXNzIGJvdGggY2FzZXMgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgdHdvPC9zcGFu PjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmFzcGVjdHMgb2YgdGhlIHNhbWUgYmFzaWMg cHJvYmxlbS4gJm5ic3A7QSBzaW5nbGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG88L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWF4aW1pemUgc2ltaWxhcml0aWVzIGFuZCBh dm9pZCB1bm5lY2Vzc2FyeSBmcmFnbWVudGF0aW9uIG9mIHRoZTwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8c3BhbiBjbGFzcz0iIj5zb2x1dGlvbnMgYW5kIGZhY2lsaXRhdGVzIGJyb2FkZXIgcmV2aWV3 Ljwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPHNwYW4gY2xhc3M9IiI+VGhlIGdyb3VwIHdpbGwgc3RhcnQgYnkgcHJvZHVjaW5nIHNwZWNp ZmljYXRpb25zIGZvciBlbWFpbCBhbmQgZm9yPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSIiPnJlYWwtdGltZSBjb21tdW5pY2F0aW9ucy48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNw YW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPkluIHRoZSBl bWFpbCBjYXNlLCB0aGUgZ3JvdXAgd2lsbCBkZXRlcm1pbmUgYSBNSU1FIGJhc2VkIHNvbHV0aW9u IChiYXNlZDwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5vbiBkcmFmdC10b21r aW5zb24tc2xpbS1tdWx0aWxhbmdjb250ZW50KSB0aGF0IGVuYWJsZXMgYSBzaW5nbGUgZW1haWw8 L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWVzc2FnZSB0byBjb250YWluIG11 bHRpcGxlIGxhbmd1YWdlIHZlcnNpb25zIG9mIHRoZSBjb250ZW50LCB3aXRoPC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnByb3Zpc2lvbnMgdG8gaGVscCBjbGllbnRzIHNlbGVj dCBhIGJlc3QtZml0IHZlcnNpb24uPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIi Pjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5JbiB0aGUgcmVhbC10aW1lIGNv bW11bmljYXRpb24gY2FzZSwgdGhlIGdyb3VwIHdpbGwgcHJvZHVjZSBhPC9zcGFuPjxiciBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSIiPnNwZWNpZmljYXRpb24gKGJhc2VkIG9uIGRyYWZ0LWdlbGxl bnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSk8L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+ZW5hYmxpbmcgbmVnb3RpYXRpb24gb2YgYSBodW1hbiBsYW5ndWFnZSBw ZXIgbWVkaWEgc3RyZWFtLiAmbmJzcDtUaGU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IiI+c3BlY2lmaWNhdGlvbiBtdXN0IGJlIHN1aXRhYmxlIGZvciB1c2UgaW4gZW1lcmdlbmN5 IGNvbW11bmljYXRpb25zIGFzPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnNw ZWNpZmllZCBpbiBSRkMgNjQ0MyBhbmQgUkZDIDY4ODEgKHdoaWNoIHVzZSBTSVAgYW5kIFNEUCB0 byBuZWdvdGlhdGU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+bWVkaWEpOyBp dCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBmb3IgdXNlIGluIG5vbi1lbWVyZ2Vu Y3k8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+cmVhbC10aW1lIGNvbW11bmlj YXRpb25zIHRoYXQgc2hhcmUgdGhlIHNhbWUgY2FsbCBzZXQtdXAgYW5kIG1lZGlhPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPm5lZ290aWF0aW9uIHByb3RvY29scy4gJm5ic3A7 VGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3MgbWVkaWEgYW5kPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmxhbmd1YWdlIG5lZWRzIGFuZCBwcmVmZXJlbmNl cyB0byBiZSBtYXRjaGVkIGFnYWluc3Qgd2hhdCB0aGUgY2FsbGVkPC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxzcGFuIGNsYXNzPSIiPnBhcnR5IGlzIGFibGUgdG8gcHJvdmlkZS4gJm5ic3A7QWx0ZXJu YXRpdmVzIHN1Y2ggYXMgZG9pbmcgdGhlIG1lZGlhPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IGNsYXNzPSIiPm5lZ290aWF0aW9uIGluIFNJUCBoYXZlIGJlZW4gZXhwbG9yZWQgaW4gdGhlIHBh c3QgYW5kIGFyZSBvdXQgb2Ygc2NvcGU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IiI+KGFsdGhvdWdoIFNJUC1iYXNlZCBtZWNoYW5pc21zIG1heSBiZSBpbnRyb2R1Y2VkIHdoZW4g cm91dGluZzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5jb25zaWRlcmF0aW9u cyBhcmUgYWRkcmVzc2VkKS48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9z cGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPlRoZSBncm91cCdzIGluaXRpYWwgZm9j dXMgd2lsbCBub3QgYmUgb24gc3VwcG9ydGluZyBsYW5ndWFnZS1iYXNlZCBjYWxsPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPnJvdXRpbmcgZGVjaXNpb25zLiAmbmJzcDtPbmNl IHRoZSBpbml0aWFsIHdvcmsgaXMgc3VmZmljaWVudGx5IHByb2dyZXNzZWQsIHRoZTwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5ncm91cCBtYXkgJm5ic3A7YWRkcmVzcyBjYWxs IHJvdXRpbmcsIHdpdGggdGhlIHRpbWluZyBhdCB0aGUganVkZ21lbnQgb2YgdGhlPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPmNoYWlycy48L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPlJlY29n bml6aW5nIHRoYXQgY29tcGxleCBzb2x1dGlvbnMgYXJlIHNpZ25pZmljYW50bHkgbGVzczwvc3Bh bj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5saWtlbHkgdG8gc2VlIHdpZGVzcHJlYWQg ZGVwbG95bWVudCwgdGhlIGdyb3VwIHdpbGwgc29sdmUgdGhlIG1vc3Q8L3NwYW4+PGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IiI+Y29tbW9uIHVzZSBjYXNlcyBhbmQgYXZvaWQgYWRkaW5nIGNv bXBsZXhpdHkgdG8gc29sdmUgZWRnZSBvcjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFz cz0iIj5sZXNzLWNvbW1vbiBjYXNlcy48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPkJ5IGFkZGluZyBsYW5ndWFn ZSB0byB0aGUgZXhpc3RpbmcgbWVkaWEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGFzIHVzZWQ8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+aW4gUkZDIDY0NDMgYW5kIFJGQyA2ODgx LCB0aGUgZ3JvdXAgY2FuIG1lZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoPC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPm1pbmltYWwgYWRkZWQgY29tcGxleGl0eSBhbmQgYmUg YWJsZSB0byBlbmhhbmNlIGxhdGVyIGZvciBhZGRpdGlvbmFsIHVzZTwvc3Bhbj48YnIgY2xhc3M9 IiI+DQo8c3BhbiBjbGFzcz0iIj5jYXNlcyBhcyBuZWVkZWQuPC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj5NaWxl c3RvbmVzOjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj4mbmJzcDtOb3YgMjAx NSAtIFN1Ym1pdCAmcXVvdDtNdWx0aXBsZSBMYW5ndWFnZSBDb250ZW50IFR5cGUmcXVvdDsgdG8g dGhlIElFU0cgKGJhc2VkPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPm9uIGRy YWZ0LXRvbWtpbnNvbi1zbGltLW11bHRpbGFuZ2NvbnRlbnQpPC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPiZuYnNwO01hciAyMDE2IC0gU3VibWl0ICZxdW90O05lZ290aWF0aW5n IEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBj bGFzcz0iIj5Db21tdW5pY2F0aW9ucyZxdW90OyB0byB0aGUgSUVTRyAoYmFzZWQgb248L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+ZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0 aW5nLWh1bWFuLWxhbmd1YWdlKTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48 L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPlNMSU0gbWFpbGluZyBs aXN0PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpT TElNQGlldGYub3JnIiBjbGFzcz0iIj5TTElNQGlldGYub3JnPC9hPjwvc3Bhbj48YnIgY2xhc3M9 IiI+DQo8c3BhbiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NsaW0iIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2xpbTwvYT48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29s b3I6Izk5OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFs OyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1p bHk6ICZxdW90O0FyaWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1h aWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBv bmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4g ZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91 IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwg b3IgY2FsbCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8 L3NwYW4+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D2CB771D870D478596612AD29EA2E56Fgsmacom_-- From nobody Mon Oct 19 02:52:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85121A87E7 for ; Mon, 19 Oct 2015 02:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmqW-6ISKFYx for ; Mon, 19 Oct 2015 02:52:30 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0661.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::661]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551501A21B0 for ; Mon, 19 Oct 2015 02:52:28 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (10.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 09:52:21 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 09:52:21 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Request for agenda items of IETF94 Thread-Index: AQHRClPZBoQU25CIH0ymJHT488zvqw== Date: Mon, 19 Oct 2015 09:52:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [118.109.86.198] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 5:79EbuvMHy5V/1ljKlJg041tOPP2YSgPIeHmDK//FOk+9kIEK3xbKtJ+aWV9tO0iqssNEFFzxvEG+A8e/yjSb71FAx9CAfyNrjfxvqv5g1ZneEEWmclvXccHFz7lwn8p8DA9JI+frq7RoFN+uQpXPJg==; 24:+WVPksI6hDxihFEJhVP/igiOJkP9RNWhHSF0tBsbb0RZFIyluB+It02R5fKbbuP4HNx06+IUDNtbo9xcvTnaC1bao8gx6Cjt42un6SgeQ5A=; 20:UlyGkGUps0Co1NkTL1Qzi0td0cKg8o+KN2tCAfYsk/6msXkhUprQxoLKX1tdnxBxN0zEX9wSWZEoXliJNgHIhQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(53754006)(199003)(189998001)(5002640100001)(15975445007)(82746002)(106356001)(2900100001)(40100003)(77096005)(87936001)(122556002)(83716003)(16236675004)(5007970100001)(105586002)(66066001)(106116001)(2351001)(229853001)(19617315012)(64706001)(5004730100002)(110136002)(46102003)(33656002)(102836002)(50226001)(101416001)(2501003)(50986999)(5890100001)(11100500001)(86362001)(97736004)(57306001)(92566002)(81156007)(5001960100002)(36756003)(19580395003)(5001920100001)(450100001)(5008740100001)(10400500002)(107886002)(19580405001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A14B11363D5D4E04BD928D4DCA793D7Cgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 09:52:21.4395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 118.109.86.198 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Request for agenda items of IETF94 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 09:52:32 -0000 --_000_A14B11363D5D4E04BD928D4DCA793D7Cgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpBcyB5b3UgY2FuIHNlZSBmcm9tIHRoZSBJRVRGOTQgYWdlbmRhIHdlIGhhdmUg YSBtZWV0aW5nIGJvb2tlZCBmb3IgMTc6MTAtMTk6MTAgb24gTW9uZGF5IEFmdGVybm9vbiBTZXNz aW9uIElJSSAod2hlcmUgSeKAmW0gZnJvbSB3ZSBjYWxsIHRoaXMgImV2ZW5pbmciIGJ1dCBvayEp Lg0KDQpCZXJuYXJkIGFuZCBJIGFyZSBub3cgcmVxdWVzdGluZyBhZ2VuZGEgaXRlbXMgZm9yIHRo aXMgbWVldGluZy4gUGxlYXNlIHNlbmQgYSBtYWlsIHRvIHRoaXMgbGlzdCB3aXRoIHN1Z2dlc3Rp b25zIGZvciB0aGUgbWVldGluZy4NCg0KQmVybmFyZCBhbHNvIHNlbnQgYSBtYWlsIHJlY2VudGx5 IGFza2luZyBpZiBhbnlvbmUgaGFzIGFueSByZXF1aXJlbWVudHMgZm9yIHRoZSBtZWV0aW5nLiBX ZSB3aWxsIG9mIGNvdXJzZSBoYXZlIHJlbW90ZSBjb25mZXJlbmNpbmcgYXZhaWxhYmxlLCBidXQg aWYgeW91IHJlcXVpcmUgYW55IG90aGVyIHN1cHBvcnQgZm9yIHRoZSBtZWV0aW5nIHBsZWFzZSBk byBsZXQgdXMga25vdy4NCg0KVGhhbmtzIGV2ZXJ5b25lIQ0KDQpOYXRhc2hhDQoNCkxpbmtzDQpE YXRhdHJhY2tlciBQYWdlDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hh cnRlci8NCk1haWwgQXJjaGl2ZQ0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jy b3dzZS9zbGltLw0KSUVURjk0DQpodHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzk0Lw0KSUVU Rjk0IEFnZW5kYQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk0L2FnZW5k YS5odG1sDQoNCg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRl cm5ldCwgVzNDICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5 QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6 IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoN Cg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUg YWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNv bWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0s IG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0 byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBl cnJvci4NCg== --_000_A14B11363D5D4E04BD928D4DCA793D7Cgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <2073F85255D15C459E3CE627C24B3C64@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+SGkgYWxsITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+QXMgeW91IGNhbiBzZWUgZnJvbSB0aGUgSUVURjk0IGFnZW5kYSB3 ZSBoYXZlIGEgbWVldGluZyBib29rZWQgZm9yJm5ic3A7MTc6MTAtMTk6MTAgb24gTW9uZGF5IEFm dGVybm9vbiBTZXNzaW9uIElJSSAod2hlcmUgSeKAmW0gZnJvbSB3ZSBjYWxsIHRoaXMgJnF1b3Q7 ZXZlbmluZyZxdW90OyBidXQgb2shKS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlcm5hcmQgYW5kIEkgYXJlIG5vdyByZXF1 ZXN0aW5nIGFnZW5kYSBpdGVtcyBmb3IgdGhpcyBtZWV0aW5nLiBQbGVhc2UmbmJzcDtzZW5kIGEg bWFpbCB0byB0aGlzIGxpc3Qgd2l0aCBzdWdnZXN0aW9ucyBmb3IgdGhlIG1lZXRpbmcuJm5ic3A7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5CZXJuYXJkIGFsc28gc2VudCBhIG1haWwgcmVjZW50bHkgYXNraW5nIGlmIGFueW9uZSBoYXMg YW55IHJlcXVpcmVtZW50cyBmb3IgdGhlIG1lZXRpbmcuIFdlIHdpbGwgb2YgY291cnNlIGhhdmUg cmVtb3RlIGNvbmZlcmVuY2luZyBhdmFpbGFibGUsIGJ1dCBpZiB5b3UgcmVxdWlyZSBhbnkgb3Ro ZXIgc3VwcG9ydCBmb3IgdGhlIG1lZXRpbmcgcGxlYXNlIGRvIGxldCB1cyBrbm93LiZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhhbmtzIGV2ZXJ5b25lITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+TmF0YXNoYTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+PHUgY2xhc3M9IiI+TGlua3M8L3U+ PC9iPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RGF0 YXRyYWNrZXIgUGFnZTwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zbGltL2NoYXJ0ZXIvIiBjbGFzcz0iIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hhcnRlci88L2E+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiIGNsYXNzPSIiPk1haWwgQXJjaGl2ZTwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zbGltLyIgY2xh c3M9IiI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zbGltLzwvYT48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+SUVURjk0PC9iPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzk0LyIgY2xhc3M9 IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy85NC88L2E+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPklFVEY5NCBBZ2VuZGE8L2I+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy85NC9hZ2VuZGEuaHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t ZWV0aW5nLzk0L2FnZW5kYS5odG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1 ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5k IEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1haWx0bzpu cm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0 NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBo cmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+ Jm5ic3A7PGJyIGNsYXNzPSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxwIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xvcjojOTk5OTk5OyI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjoj OTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0LXRoZW1l LWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVv dDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdC OyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1l bnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25m aWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtl IG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0g dG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICYjNDM7NDQgMjA3 IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_A14B11363D5D4E04BD928D4DCA793D7Cgsmacom_-- From nobody Mon Oct 19 12:00:50 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29B31B2C5E; Mon, 19 Oct 2015 12:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaatoAOCHdAU; Mon, 19 Oct 2015 12:00:46 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 668241B2BE3; Mon, 19 Oct 2015 12:00:34 -0700 (PDT) Received: by qkfm62 with SMTP id m62so87003062qkf.1; Mon, 19 Oct 2015 12:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lVt+3fnBRwzJ+t8fgAJuJblj68M+d1G9KIz5GvKARsU=; b=pSr0LouPAhM4J/51zHtLSBBSh/KI/OjEHFRkBakWDj7HbASO+gjvE4EvVKiAqdosrY rSS1wJbPNr8eEubQWShGHxh7d2NT5LzWeA4lWOdGAcSgtgD135ah2poU68j97tE2I5OI 1S3Y69f8lp4QOpDfHbgWig6F6cVCKuIJ+fP05bxPC9QpX34cEWeh/PpP4jKmpB5jdh6m tJJR00QTJwj9LYWzD7DDV4wF3Pbxr2k7W41s5nUOciRuIa2z64XlgbUVDZWPMcz5D5sz DJ2ShZAk7AkxSZeXQKEFBJQBaOzac5CBlb8oQBg0aCjQYt3jbyd6+Deeaow1xV8xlnnh frMA== MIME-Version: 1.0 X-Received: by 10.55.197.29 with SMTP id p29mr37717058qki.82.1445281233425; Mon, 19 Oct 2015 12:00:33 -0700 (PDT) Received: by 10.233.222.133 with HTTP; Mon, 19 Oct 2015 12:00:33 -0700 (PDT) In-Reply-To: <20151016165330.12818.19572.idtracker@ietfa.amsl.com> References: <20151016165330.12818.19572.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 20:00:33 +0100 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a1149e99a84efff052279c2c4 Archived-At: Cc: slim-chairs@ietf.org Subject: Re: [Slim] WG Action: Formed Selection of Language for Internet Media (slim) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:00:49 -0000 --001a1149e99a84efff052279c2c4 Content-Type: text/plain; charset=UTF-8 Hi All, I mentioned this off list to Randall, but the Milestone for draft-tomkinson-slim-multilangcontent needs to be updated to Mar 2016 as there is some testing required for further refinement and also some thinking on a new section so this will not meet the original deadline of November. Can this get updated please? Thanks, Nik. On 16 October 2015 at 17:53, The IESG wrote: > A new IETF working group has been formed in the Applications and > Real-Time Area. For additional information please contact the Area > Directors or the WG Chairs. > > Selection of Language for Internet Media (slim) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Bernard Aboba > N Rooney > > Assigned Area Director: > Barry Leiba > > Mailing list > Address: slim@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/slim > Archive: https://mailarchive.ietf.org/arch/browse/slim/ > > Charter: > > A mutually comprehensible language is helpful for human communication. > This is true across a range of circumstances and environments. In > general, the problem is most acute in situations where there is not a > clear choice for a single language, such as environments lacking > contextual or out-of-band information regarding the identity of the > parties and the language to be used. > > The group will address two specific cases that most urgently need a > technical solution: One problem space is non-real-time communication, > specifically email for one-to-many or where the set of recipients is > dynamic or different recipients require different languages; the other > is real-time communication, specifically emergency calling, preferably > also useful for other cases where the parties may not know each other > personally or where one party wishes to accommodate people with varying > language and media needs. > > In the real-time communication case, language and media are > intrinsically linked, for example, signed languages require a video > media. > > While the two use cases are in different contexts (real time and > non-real-time), the fundamental goal is the same: to enable selection of > the best-fit language(s) for a specific situation. Some of the details > will also be in common across the cases, e.g., the language tags. > Having a single WG address both cases makes it clear that these are two > aspects of the same basic problem. A single WG also makes it easier to > maximize similarities and avoid unnecessary fragmentation of the > solutions and facilitates broader review. > > The group will start by producing specifications for email and for > real-time communications. > > In the email case, the group will determine a MIME based solution (based > on draft-tomkinson-slim-multilangcontent) that enables a single email > message to contain multiple language versions of the content, with > provisions to help clients select a best-fit version. > > In the real-time communication case, the group will produce a > specification (based on draft-gellens-slim-negotiating-human-language) > enabling negotiation of a human language per media stream. The > specification must be suitable for use in emergency communications as > specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate > media); it is desirable to also be suitable for use in non-emergency > real-time communications that share the same call set-up and media > negotiation protocols. The mechanism will permit the caller's media and > language needs and preferences to be matched against what the called > party is able to provide. Alternatives such as doing the media > negotiation in SIP have been explored in the past and are out of scope > (although SIP-based mechanisms may be introduced when routing > considerations are addressed). > > The group's initial focus will not be on supporting language-based call > routing decisions. Once the initial work is sufficiently progressed, the > group may address call routing, with the timing at the judgment of the > chairs. > > Recognizing that complex solutions are significantly less > likely to see widespread deployment, the group will solve the most > common use cases and avoid adding complexity to solve edge or > less-common cases. > > By adding language to the existing media negotiation mechanism as used > in RFC 6443 and RFC 6881, the group can meet the basic use cases with > minimal added complexity and be able to enhance later for additional use > cases as needed. > > Milestones: > Nov 2015 - Submit "Multiple Language Content Type" to the IESG (based > on draft-tomkinson-slim-multilangcontent) > Mar 2016 - Submit "Negotiating Human Language in Real-Time > Communications" to the IESG (based on > draft-gellens-slim-negotiating-human-language) > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a1149e99a84efff052279c2c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I mentioned this off list to Ra= ndall, but the Milestone for=C2=A0draft-to= mkinson-slim-multilangcontent needs= to be updated to=C2=A0Mar 2016 as = there is some testing required for further refinement and also some thinkin= g on a new section so this will not meet the original deadline of November.=

Can this get updated please?

Thanks,
Nik.

On 16 October 20= 15 at 17:53, The IESG <iesg-secretary@ietf.org> wrote:=
A new IETF working group has been formed= in the Applications and
Real-Time Area. For additional information please contact the Area
Directors or the WG Chairs.

Selection of Language for Internet Media (slim)
------------------------------------------------
Current Status: Proposed WG

Chairs:
=C2=A0 Bernard Aboba <Berna= rd_Aboba@hotmail.com>
=C2=A0 N Rooney <nrooney@gsma.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleib= a@computer.org>

Mailing list
=C2=A0 Address: slim@ietf.org
=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo= /slim
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/slim/

Charter:

A mutually comprehensible language is helpful for human communication.
This is true across a range of circumstances and environments.=C2=A0 In
general, the problem is most acute in situations where there is not a
clear choice for a single language, such as environments lacking
contextual or out-of-band information regarding the identity of the
parties and the language to be used.

The group will address two specific cases that most urgently need a
technical solution: One problem space is non-real-time communication,
specifically email for one-to-many or where the set of recipients is
dynamic or different recipients require different languages; the other
is real-time communication, specifically emergency calling, preferably
also useful for other cases where the parties may not know each other
personally or where one party wishes to accommodate people with varying
language and media needs.

In the real-time communication case, language and media are
intrinsically linked, for example, signed languages require a video
media.

While the two use cases are in different contexts (real time and
non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation.=C2=A0 Some of the detail= s
will also be in common across the cases, e.g., the language tags.
Having a single WG address both cases makes it clear that these are two
aspects of the same basic problem.=C2=A0 A single WG also makes it easier t= o
maximize similarities and avoid unnecessary fragmentation of the
solutions and facilitates broader review.

The group will start by producing specifications for email and for
real-time communications.

In the email case, the group will determine a MIME based solution (based on draft-tomkinson-slim-multilangcontent) that enables a single email
message to contain multiple language versions of the content, with
provisions to help clients select a best-fit version.

In the real-time communication case, the group will produce a
specification (based on draft-gellens-slim-negotiating-human-language)
enabling negotiation of a human language per media stream.=C2=A0 The
specification must be suitable for use in emergency communications as
specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate
media); it is desirable to also be suitable for use in non-emergency
real-time communications that share the same call set-up and media
negotiation protocols.=C2=A0 The mechanism will permit the caller's med= ia and
language needs and preferences to be matched against what the called
party is able to provide.=C2=A0 Alternatives such as doing the media
negotiation in SIP have been explored in the past and are out of scope
(although SIP-based mechanisms may be introduced when routing
considerations are addressed).

The group's initial focus will not be on supporting language-based call=
routing decisions.=C2=A0 Once the initial work is sufficiently progressed, = the
group may=C2=A0 address call routing, with the timing at the judgment of th= e
chairs.

Recognizing that complex solutions are significantly less
likely to see widespread deployment, the group will solve the most
common use cases and avoid adding complexity to solve edge or
less-common cases.

By adding language to the existing media negotiation mechanism as used
in RFC 6443 and RFC 6881, the group can meet the basic use cases with
minimal added complexity and be able to enhance later for additional use cases as needed.

Milestones:
=C2=A0 Nov 2015 - Submit "Multiple Language Content Type" to the = IESG (based
on draft-tomkinson-slim-multilangcontent)
=C2=A0 Mar 2016 - Submit "Negotiating Human Language in Real-Time
Communications" to the IESG (based on
draft-gellens-slim-negotiating-human-language)


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



-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/= 
----------------=
-------------------------------------------------
--001a1149e99a84efff052279c2c4-- From nobody Tue Oct 20 02:03:30 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBF11A7022 for ; Tue, 20 Oct 2015 02:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khh2ap9jPSWK for ; Tue, 20 Oct 2015 02:03:24 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8F51A7014 for ; Tue, 20 Oct 2015 02:03:21 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (10.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.300.14; Tue, 20 Oct 2015 09:03:01 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0300.010; Tue, 20 Oct 2015 09:03:02 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Reviewing our proposed work items Thread-Index: AQHRCxYfhKic9lfr30uIVcNckR7xkg== Date: Tue, 20 Oct 2015 09:03:02 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [219.108.220.186] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 5:8uUQfouOftfJyPvVdUIL7GRhz0Vy73ThwbkGKo9ifKJmqqmdXWRYWlgz3OLD/PjvLqTMBKFYtcCO5XXStjizaQUl/o+qcWa2yCNdnGm3+ovWZN/i/nVcxAIHq4Nn6s4hSfvP0fuB8G6VPBo3rnLEHA==; 24:EWo/UlM5WfvXXaEOmYo1yeLtPMF4wIvXdAlhuWNV4e5LyKIMIBeIFpLiw6ui62dJ8o0tDHz7zAxtNPktgQZV/fN3bAxekQy2gwahFiZ4GCI=; 20:cpR4orJljjem24Lgmgqsbpf4cJ2iq8iN8D+DJS5gM2eXPAPZ4KmJWa2KejBaYOwbTKkwNad9vTOS7wdFzEY7uA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 073515755F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(53754006)(199003)(82746002)(57306001)(189998001)(19617315012)(106356001)(87936001)(2900100001)(40100003)(15975445007)(77096005)(5002640100001)(122556002)(66066001)(16236675004)(83716003)(2351001)(106116001)(64706001)(5004730100002)(5007970100001)(105586002)(229853001)(102836002)(2501003)(33656002)(5890100001)(101416001)(5008740100001)(50226001)(50986999)(86362001)(97736004)(5001960100002)(36756003)(81156007)(10400500002)(92566002)(110136002)(19580395003)(5001920100001)(19580405001)(107886002)(450100001)(46102003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C9C30A0611464962BAF0FA20515F4E35gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2015 09:03:02.0181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 219.108.220.186 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Reviewing our proposed work items X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 09:03:28 -0000 --_000_C9C30A0611464962BAF0FA20515F4E35gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpXZSBjdXJyZW50bHkgaGF2ZSB0d28gZG9jdW1lbnRzIGFzIHByb3Bvc2VkIFdH IGl0ZW1zOg0KDQpOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRpbWUgQ29tbXVu aWNhdGlvbnMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdlbGxlbnMt c2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS8NCk11bHRpcGxlIExhbmd1YWdlIENvbnRl bnQgVHlwZQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdG9ta2luc29u LXNsaW0tbXVsdGlsYW5nY29udGVudC8NCg0KTm93IHRoYXQgdGhlIGdyb3VwIGhhcyBiZWVuIG9m ZmljaWFsbHkgc3RhcnRlZCBpdOKAmXMgdGltZSBmb3IgdXMgdG8gcmV2aWV3IHRoZXNlIGRvY3Vt ZW50cy4gUGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZXNlIGFuZCBzZW5kIGFueSBjb21tZW50cyB0 byB0aGUgbGlzdC4gT2YgY291cnNlIGtlZXAgYW4gZXllIG91dCBmb3IgdGhlIHVzdWFsIHN0dWZm OiBmZWFzaWJpbGl0eSwgc2VjdXJpdHksIGNvcnJlY3QgcHJvdG9jb2wgcmV1c2UsIGZvcm1hdHRp bmcgZXRjLi4gV2Ugd2lsbCBkaXNjdXNzIGlzc3VlcyBvbi1saXN0IGFuZCBhdCB0aGUgbWVldGlu ZyBhdCBJRVRGOTQuIFBsZWFzZSBhc2sgaWYgdGhlcmUgYXJlIGFueSBxdWVzdGlvbnMhDQoNCk5h dGFzaGENCg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5l dCwgVzNDICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdz bWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5y b29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoNCg0K DQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJv dmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUg dG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5v ciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0 aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJv ci4NCg== --_000_C9C30A0611464962BAF0FA20515F4E35gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBhbGwh PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5XZSBjdXJyZW50bHkgaGF2ZSB0d28gZG9jdW1lbnRzIGFzIHByb3Bvc2VkIFdHIGl0ZW1zOjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPk5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlIGlu IFJlYWwtVGltZSBDb21tdW5pY2F0aW9uczwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VsbGVucy1zbGltLW5l Z290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdl LzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+TXVsdGlwbGUgTGFuZ3VhZ2Ug Q29udGVudCBUeXBlPC9iPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRvbWtpbnNvbi1zbGltLW11bHRp bGFuZ2NvbnRlbnQvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC10b21raW5zb24tc2xpbS1tdWx0aWxhbmdjb250ZW50LzwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk5vdyB0aGF0IHRoZSBn cm91cCBoYXMgYmVlbiBvZmZpY2lhbGx5IHN0YXJ0ZWQgaXTigJlzIHRpbWUgZm9yIHVzIHRvIHJl dmlldyB0aGVzZSBkb2N1bWVudHMuIFBsZWFzZSB0YWtlIGEgbG9vayZuYnNwO2F0IHRoZXNlIGFu ZCBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgbGlzdC4gT2YgY291cnNlIGtlZXAgYW4gZXllIG91 dCBmb3IgdGhlIHVzdWFsIHN0dWZmOiBmZWFzaWJpbGl0eSwgc2VjdXJpdHksIGNvcnJlY3QgcHJv dG9jb2wgcmV1c2UsDQogZm9ybWF0dGluZyZuYnNwO2V0Yy4uIFdlIHdpbGwgZGlzY3VzcyBpc3N1 ZXMgb24tbGlzdCBhbmQgYXQgdGhlIG1lZXRpbmcgYXQgSUVURjk0LiZuYnNwO1BsZWFzZSBhc2sg aWYgdGhlcmUgYXJlIGFueSBxdWVzdGlvbnMhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5OYXRhc2hhPC9kaXY+DQo8ZGl2IGFwcGxlLWNv bnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYSBSb29uZXkgfCBUZWNo bm9sb2dpc3QsIFdlYiBhbmQgSW50ZXJuZXQsIFczQyAmYW1wOyBJRVRGIHwmbmJzcDtHU01BIHwg PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtYS5jb20iIGNsYXNzPSIiPg0KbnJvb25leUBnc21h LmNvbTwvYT4gfCAmIzQzOzQ0ICgwKSZuYnNwOzc3MzAgMjE5IDc2NSB8IEB0aGlzTmF0YXNoYSB8 IFNreXBlOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbS5vcmciIGNsYXNzPSIiPm5y b29uZXlAZ3NtLm9yZzwvYT4mbmJzcDs8YnIgY2xhc3M9IiI+DQpUb2t5bywgSmFwYW48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPHAg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9y OiM5OTk5OTk7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxz YW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsg bXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogRU4tR0I7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWls IGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25s eSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVy cm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBj b3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9y IGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9z cGFuPjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C9C30A0611464962BAF0FA20515F4E35gsmacom_-- From nobody Tue Oct 20 08:47:57 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6801A9253 for ; Tue, 20 Oct 2015 08:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhNd7yy1NGNS for ; Tue, 20 Oct 2015 08:47:54 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C491AC3EF for ; Tue, 20 Oct 2015 08:47:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="scan'208,217";a="343540005" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-71009.iad55.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2015 15:47:47 +0000 Received: from ex10-hub-7002.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com [10.0.103.150]) by email-inbound-relay-71009.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id t9KFlQon026424 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2015 15:47:46 GMT Received: from EX13D08UWC002.ant.amazon.com (10.43.162.168) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 20 Oct 2015 08:47:28 -0700 Received: from EX13D08UWC002.ant.amazon.com (10.43.162.168) by EX13D08UWC002.ant.amazon.com (10.43.162.168) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 20 Oct 2015 15:47:25 +0000 Received: from EX13D08UWC002.ant.amazon.com ([10.43.162.168]) by EX13D08UWC002.ant.amazon.com ([10.43.162.168]) with mapi id 15.00.1076.000; Tue, 20 Oct 2015 15:47:25 +0000 From: "Phillips, Addison" To: Natasha Rooney , "slim@ietf.org" Thread-Topic: Reviewing our proposed work items Thread-Index: AQHRCxYfhKic9lfr30uIVcNckR7xkp50hpVA Date: Tue, 20 Oct 2015 15:47:25 +0000 Message-ID: References: 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.235] Content-Type: multipart/alternative; boundary="_000_e6d4a61a82a2492ba5ef3d3d0c059145EX13D08UWC002antamazonc_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Slim] Reviewing our proposed work items X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 15:47:56 -0000 --_000_e6d4a61a82a2492ba5ef3d3d0c059145EX13D08UWC002antamazonc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIGRyYWZ0LXRvbWtpbnNvbiBhbmQgaGF2ZSBzb21lIGNvbW1lbnRzLiBEb2VzIHRoZSBn cm91cCBwcmVmZXIgb25lIGNvbW1lbnQgcGVyIGVtYWlsIG9yIGFsbCBpbiBhIHNpbmdsZSBlbWFp bD8NCg0KQWRkaXNvbiBQaGlsbGlwcw0KUHJpbmNpcGFsIFNERSwgSTE4TiBBcmNoaXRlY3QgKEFt YXpvbikNCkNoYWlyIChXM0MgSTE4TiBXRykNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90 IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KDQoNCkZyb206IFNMSU0gW21h aWx0bzpzbGltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXRhc2hhIFJvb25leQ0K U2VudDogVHVlc2RheSwgT2N0b2JlciAyMCwgMjAxNSAyOjAzIEFNDQpUbzogc2xpbUBpZXRmLm9y Zw0KU3ViamVjdDogW1NsaW1dIFJldmlld2luZyBvdXIgcHJvcG9zZWQgd29yayBpdGVtcw0KDQpI aSBhbGwhDQoNCldlIGN1cnJlbnRseSBoYXZlIHR3byBkb2N1bWVudHMgYXMgcHJvcG9zZWQgV0cg aXRlbXM6DQoNCk5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZSBDb21tdW5p Y2F0aW9ucw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VsbGVucy1z bGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLw0KTXVsdGlwbGUgTGFuZ3VhZ2UgQ29udGVu dCBUeXBlDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10b21raW5zb24t c2xpbS1tdWx0aWxhbmdjb250ZW50Lw0KDQpOb3cgdGhhdCB0aGUgZ3JvdXAgaGFzIGJlZW4gb2Zm aWNpYWxseSBzdGFydGVkIGl04oCZcyB0aW1lIGZvciB1cyB0byByZXZpZXcgdGhlc2UgZG9jdW1l bnRzLiBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlc2UgYW5kIHNlbmQgYW55IGNvbW1lbnRzIHRv IHRoZSBsaXN0LiBPZiBjb3Vyc2Uga2VlcCBhbiBleWUgb3V0IGZvciB0aGUgdXN1YWwgc3R1ZmY6 IGZlYXNpYmlsaXR5LCBzZWN1cml0eSwgY29ycmVjdCBwcm90b2NvbCByZXVzZSwgZm9ybWF0dGlu ZyBldGMuLiBXZSB3aWxsIGRpc2N1c3MgaXNzdWVzIG9uLWxpc3QgYW5kIGF0IHRoZSBtZWV0aW5n IGF0IElFVEY5NC4gUGxlYXNlIGFzayBpZiB0aGVyZSBhcmUgYW55IHF1ZXN0aW9ucyENCg0KTmF0 YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0 LCBXM0MgJiBJRVRGIHwgR1NNQSB8IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3Nt YS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJv b25leUBnc20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5vcmc+DQpUb2t5bywgSmFwYW4NCg0KDQpU aGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUg bmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8g eW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBt dXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlz IGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4N Cg== --_000_e6d4a61a82a2492ba5ef3d3d0c059145EX13D08UWC002antamazonc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg cmVhZCBkcmFmdC10b21raW5zb24gYW5kIGhhdmUgc29tZSBjb21tZW50cy4gRG9lcyB0aGUgZ3Jv dXAgcHJlZmVyIG9uZSBjb21tZW50IHBlciBlbWFpbCBvciBhbGwgaW4gYSBzaW5nbGUgZW1haWw/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkFkZGlzb24gUGhpbGxpcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5QcmluY2lwYWwgU0RFLCBJMThOIEFyY2hpdGVjdCAoQW1hem9uKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNoYWlyIChXM0MgSTE4TiBXRyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3Qg YSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkl0IGlz IGFuIGFyY2hpdGVjdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFNMSU0gW21haWx0bzpzbGltLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5hdGFzaGEgUm9vbmV5PGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIE9jdG9iZXIgMjAsIDIwMTUgMjowMyBBTTxicj4NCjxiPlRvOjwvYj4gc2xpbUBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbU2xpbV0gUmV2aWV3aW5nIG91ciBwcm9wb3NlZCB3 b3JrIGl0ZW1zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIGFsbCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2UgY3VycmVudGx5IGhhdmUgdHdvIGRvY3VtZW50cyBhcyBwcm9wb3NlZCBX RyBpdGVtczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPk5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZSBD b21tdW5pY2F0aW9uczwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWdlbGxlbnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdlbGxlbnMtc2xpbS1uZWdvdGlhdGluZy1odW1h bi1sYW5ndWFnZS88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5NdWx0aXBsZSBMYW5ndWFnZSBDb250ZW50IFR5cGU8L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRvbWtpbnNvbi1zbGlt LW11bHRpbGFuZ2NvbnRlbnQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10b21raW5zb24tc2xpbS1tdWx0aWxhbmdjb250ZW50LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm93IHRoYXQgdGhlIGdyb3VwIGhh cyBiZWVuIG9mZmljaWFsbHkgc3RhcnRlZCBpdOKAmXMgdGltZSBmb3IgdXMgdG8gcmV2aWV3IHRo ZXNlIGRvY3VtZW50cy4gUGxlYXNlIHRha2UgYSBsb29rJm5ic3A7YXQgdGhlc2UgYW5kIHNlbmQg YW55IGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBPZiBjb3Vyc2Uga2VlcCBhbiBleWUgb3V0IGZvciB0 aGUgdXN1YWwgc3R1ZmY6IGZlYXNpYmlsaXR5LCBzZWN1cml0eSwgY29ycmVjdCBwcm90b2NvbA0K IHJldXNlLCBmb3JtYXR0aW5nJm5ic3A7ZXRjLi4gV2Ugd2lsbCBkaXNjdXNzIGlzc3VlcyBvbi1s aXN0IGFuZCBhdCB0aGUgbWVldGluZyBhdCBJRVRGOTQuJm5ic3A7UGxlYXNlIGFzayBpZiB0aGVy ZSBhcmUgYW55IHF1ZXN0aW9ucyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TmF0YXNoYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQpOYXRhc2hhIFJvb25leSB8IFRl Y2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICZhbXA7IElFVEYgfCZuYnNwO0dTTUEg fCA8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21hLmNvbSI+DQpucm9vbmV5QGdzbWEuY29tPC9h PiB8ICYjNDM7NDQgKDApJm5ic3A7NzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6 Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtLm9yZyI+bnJvb25leUBnc20ub3JnPC9h PiZuYnNwOzxicj4NClRva3lvLCBKYXBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5UaGlz IGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFt ZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91 IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uDQogYmFzZWQgb24gdGhlbSwgbm9yIG11 c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMg ZW1haWwgb3IgY2FsbCAmIzQzOzQ0IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJv ci4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e6d4a61a82a2492ba5ef3d3d0c059145EX13D08UWC002antamazonc_-- From nobody Tue Oct 20 18:45:16 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30671B2C48 for ; Tue, 20 Oct 2015 18:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2OdclOMH_Ex for ; Tue, 20 Oct 2015 18:45:11 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0646.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::646]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194F71B2C46 for ; Tue, 20 Oct 2015 18:45:09 -0700 (PDT) Received: from DB5PR04MB1029.eurprd04.prod.outlook.com (10.161.199.143) by DB5PR04MB1031.eurprd04.prod.outlook.com (10.161.199.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Wed, 21 Oct 2015 01:45:02 +0000 Received: from DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) by DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) with mapi id 15.01.0300.010; Wed, 21 Oct 2015 01:45:02 +0000 From: Natasha Rooney To: "Phillips, Addison" Thread-Topic: Reviewing our proposed work items Thread-Index: AQHRCxYg5YcRH3CC7UmCSlVSnPUgF550hw6AgACm9wA= Date: Wed, 21 Oct 2015 01:45:02 +0000 Message-ID: <27207700-D0A6-475D-AB11-7BE5F8E9AB0B@gsma.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [219.108.220.186] x-microsoft-exchange-diagnostics: 1; DB5PR04MB1031; 5:/mLgBjVldajCTqvYmmNg5cyRA3oE2uj5IHPUJIX2w3IzRgXtftQXPIV4MzAp1V6Bot4AkDV+nkBeh5XZOWPvVroMhooEQE0x9t3q+KiOnAXHc0BxI0WMxXb1Cz1VtFQMsjXAsP3xwkLvWgV2QQEFCA==; 24:peRRdmrDGr3Zkqw6GGFou3qtdsOdcWHWiUYJf3XVARIOha4drxxbSZgHOt8bcBzzGndCExH0kJZoi/NSJWkbP70l/3hbFINwenCx+pPTVf4=; 20:62iOuRYzbLLa0gTYKEFCW7uV9RP0kNLEKZ7lnrlcw0ZRcjO/TWQd7ACNHOAM9u/EFyB0wHUUF8jlP0ZhsQ/28w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1031; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001); SRVR:DB5PR04MB1031; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1031; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(53754006)(52604005)(199003)(189002)(377454003)(46102003)(5001960100002)(77096005)(5007970100001)(5002640100001)(15975445007)(64706001)(50986999)(76176999)(66066001)(102836002)(83716003)(16236675004)(50226001)(87936001)(19580395003)(101416001)(10400500002)(106356001)(57306001)(105586002)(106116001)(19580405001)(86362001)(122556002)(19617315012)(5008740100001)(81156007)(5004730100002)(33656002)(36756003)(92566002)(97736004)(110136002)(189998001)(82746002)(5890100001)(11100500001)(40100003)(2950100001)(2900100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1031; H:DB5PR04MB1029.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_27207700D0A6475DAB117BE5F8E9AB0Bgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 01:45:02.0874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1031 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DB5PR04MB1029.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 219.108.220.186 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: DB5PR04MB1031.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] Reviewing our proposed work items X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 01:45:15 -0000 --_000_27207700D0A6475DAB117BE5F8E9AB0Bgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsIGluIHRoZSBzYW1lIG1haWwgaXMgZ29vZCBBZGRpc29uIC0gSeKAmWxsIHNlcGFyYXRlIHRo ZW0gb3V0IGludG8gZGlmZmVyZW50IHRocmVhZHMgaWYgdGhlIGRpc2N1c3Npb24gZ2V0cyB1bm1h bmFnZWFibGUuDQoNClRoYW5rcyBmb3IgY2hlY2tpbmchDQoNCk5hdGFzaGENCg0KDQpOYXRhc2hh IFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICYgSUVURiB8IEdT TUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAoMCkg NzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxtYWls dG86bnJvb25leUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoNCg0KT24gT2N0IDIxLCAyMDE1LCBh dCAxMjo0NyBBTSwgUGhpbGxpcHMsIEFkZGlzb24gPGFkZGlzb25AbGFiMTI2LmNvbTxtYWlsdG86 YWRkaXNvbkBsYWIxMjYuY29tPj4gd3JvdGU6DQoNCkkgcmVhZCBkcmFmdC10b21raW5zb24gYW5k IGhhdmUgc29tZSBjb21tZW50cy4gRG9lcyB0aGUgZ3JvdXAgcHJlZmVyIG9uZSBjb21tZW50IHBl ciBlbWFpbCBvciBhbGwgaW4gYSBzaW5nbGUgZW1haWw/DQoNCkFkZGlzb24gUGhpbGxpcHMNClBy aW5jaXBhbCBTREUsIEkxOE4gQXJjaGl0ZWN0IChBbWF6b24pDQpDaGFpciAoVzNDIEkxOE4gV0cp DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNo aXRlY3R1cmUuDQoNCg0KDQpGcm9tOiBTTElNIFttYWlsdG86c2xpbS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTmF0YXNoYSBSb29uZXkNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjAs IDIwMTUgMjowMyBBTQ0KVG86IHNsaW1AaWV0Zi5vcmc8bWFpbHRvOnNsaW1AaWV0Zi5vcmc+DQpT dWJqZWN0OiBbU2xpbV0gUmV2aWV3aW5nIG91ciBwcm9wb3NlZCB3b3JrIGl0ZW1zDQoNCkhpIGFs bCENCg0KV2UgY3VycmVudGx5IGhhdmUgdHdvIGRvY3VtZW50cyBhcyBwcm9wb3NlZCBXRyBpdGVt czoNCg0KTmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lIENvbW11bmljYXRp b25zDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nZWxsZW5zLXNsaW0t bmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UvDQpNdWx0aXBsZSBMYW5ndWFnZSBDb250ZW50IFR5 cGUNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRvbWtpbnNvbi1zbGlt LW11bHRpbGFuZ2NvbnRlbnQvDQoNCk5vdyB0aGF0IHRoZSBncm91cCBoYXMgYmVlbiBvZmZpY2lh bGx5IHN0YXJ0ZWQgaXTigJlzIHRpbWUgZm9yIHVzIHRvIHJldmlldyB0aGVzZSBkb2N1bWVudHMu IFBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGVzZSBhbmQgc2VuZCBhbnkgY29tbWVudHMgdG8gdGhl IGxpc3QuIE9mIGNvdXJzZSBrZWVwIGFuIGV5ZSBvdXQgZm9yIHRoZSB1c3VhbCBzdHVmZjogZmVh c2liaWxpdHksIHNlY3VyaXR5LCBjb3JyZWN0IHByb3RvY29sIHJldXNlLCBmb3JtYXR0aW5nIGV0 Yy4uIFdlIHdpbGwgZGlzY3VzcyBpc3N1ZXMgb24tbGlzdCBhbmQgYXQgdGhlIG1lZXRpbmcgYXQg SUVURjk0LiBQbGVhc2UgYXNrIGlmIHRoZXJlIGFyZSBhbnkgcXVlc3Rpb25zIQ0KDQpOYXRhc2hh DQoNCg0KTmF0YXNoYSBSb29uZXkgfCBUZWNobm9sb2dpc3QsIFdlYiBhbmQgSW50ZXJuZXQsIFcz QyAmIElFVEYgfCBHU01BIHwgbnJvb25leUBnc21hLmNvbTxtYWlsdG86bnJvb25leUBnc21hLmNv bT4gfCArNDQgKDApIDc3MzAgMjE5IDc2NSB8IEB0aGlzTmF0YXNoYSB8IFNreXBlOiBucm9vbmV5 QGdzbS5vcmc8bWFpbHRvOm5yb29uZXlAZ3NtLm9yZz4NClRva3lvLCBKYXBhbg0KDQoNClRoaXMg ZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1l ZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3Ug aW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3Qg eW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1h aWwgb3IgY2FsbCArNDQgMjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0KDQoN ClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92 ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0 byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9y IG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRo aXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9y Lg0K --_000_27207700D0A6475DAB117BE5F8E9AB0Bgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVk aXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFs bCBpbiB0aGUgc2FtZSBtYWlsIGlzIGdvb2QgQWRkaXNvbiAtIEnigJlsbCBzZXBhcmF0ZSB0aGVt IG91dCBpbnRvIGRpZmZlcmVudCB0aHJlYWRzIGlmIHRoZSBkaXNjdXNzaW9uIGdldHMgdW5tYW5h Z2VhYmxlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyBmb3IgY2hlY2tpbmch PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBX ZWIgYW5kIEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1h aWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208L2E+IHwg JiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTombmJz cDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5v cmc8L2E+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gT2N0IDIxLCAyMDE1 LCBhdCAxMjo0NyBBTSwgUGhpbGxpcHMsIEFkZGlzb24gJmx0OzxhIGhyZWY9Im1haWx0bzphZGRp c29uQGxhYjEyNi5jb20iIGNsYXNzPSIiPmFkZGlzb25AbGFiMTI2LmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlv bjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj5JIHJlYWQgZHJhZnQtdG9ta2luc29uIGFuZCBoYXZlIHNvbWUgY29tbWVudHMuIERv ZXMgdGhlIGdyb3VwIHByZWZlciBvbmUgY29tbWVudCBwZXIgZW1haWwgb3IgYWxsIGluIGEgc2lu Z2xlIGVtYWlsPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj5BZGRpc29uIFBoaWxsaXBzPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dy b3VuZC1jb2xvcjogd2hpdGU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+UHJpbmNpcGFs IFNERSwgSTE4TiBBcmNoaXRlY3QgKEFtYXpvbik8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWNv bG9yOiB3aGl0ZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5DaGFpciAoVzNDIEkxOE4g V0cpPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuPG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+SXQgaXMgYW4gYXJjaGl0ZWN0dXJlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxl ZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGluIDBp biAwaW4gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVy LXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwg MjI1KTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNMSU0g WzxhIGhyZWY9Im1haWx0bzpzbGltLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpz bGltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TmF0YXNoYSBSb29uZXk8YnIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgT2N0b2JlciAyMCwgMjAxNSAyOjAzIEFN PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2xpbUBpZXRmLm9yZyIg Y2xhc3M9IiI+c2xpbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ W1NsaW1dIFJldmlld2luZyBvdXIgcHJvcG9zZWQgd29yayBpdGVtczxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQpIaSBhbGwhPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCldl IGN1cnJlbnRseSBoYXZlIHR3byBkb2N1bWVudHMgYXMgcHJvcG9zZWQgV0cgaXRlbXM6PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij5OZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbnM8 L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nZWxsZW5zLXNsaW0tbmVnb3Rp YXRpbmctaHVtYW4tbGFuZ3VhZ2UvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1nZWxsZW5zLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UvPC9hPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+TXVsdGlw bGUgTGFuZ3VhZ2UgQ29udGVudCBUeXBlPC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC10b21raW5zb24tc2xpbS1tdWx0aWxhbmdjb250ZW50LyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdG9ta2luc29uLXNsaW0tbXVsdGlsYW5n Y29udGVudC88L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk5vdyB0aGF0 IHRoZSBncm91cCBoYXMgYmVlbiBvZmZpY2lhbGx5IHN0YXJ0ZWQgaXTigJlzIHRpbWUgZm9yIHVz IHRvIHJldmlldyB0aGVzZSBkb2N1bWVudHMuIFBsZWFzZSB0YWtlIGEgbG9vayZuYnNwO2F0IHRo ZXNlIGFuZCBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgbGlzdC4gT2YgY291cnNlIGtlZXAgYW4g ZXllIG91dCBmb3IgdGhlIHVzdWFsIHN0dWZmOiBmZWFzaWJpbGl0eSwgc2VjdXJpdHksIGNvcnJl Y3QgcHJvdG9jb2wgcmV1c2UsIGZvcm1hdHRpbmcmbmJzcDtldGMuLg0KIFdlIHdpbGwgZGlzY3Vz cyBpc3N1ZXMgb24tbGlzdCBhbmQgYXQgdGhlIG1lZXRpbmcgYXQgSUVURjk0LiZuYnNwO1BsZWFz ZSBhc2sgaWYgdGhlcmUgYXJlIGFueSBxdWVzdGlvbnMhPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCk5hdGFzaGE8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2Vi IGFuZCBJbnRlcm5ldCwgVzNDICZhbXA7IElFVEYgfCZuYnNwO0dTTUEgfDxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bnJvb25l eUBnc21hLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+bnJvb25leUBnc21hLmNvbTwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+fA0KICYjNDM7NDQgKDApJm5ic3A7NzczMCAyMTkg NzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlA Z3NtLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNwOzxiciBjbGFzcz0iIj4NClRva3lv LCBKYXBhbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsg Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDE1MywgMTUzLCAxNTMp OyIgY2xhc3M9IiI+VGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBm b3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkg aGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZA0K IG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFz ZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDAgYW5kIGhp Z2hsaWdodCB0aGUgZXJyb3IuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5 OTk5OTk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUt Zm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90 OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7 IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVu dHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZp ZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ug bm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0 byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcg MzU2IDA2MDANCiBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_27207700D0A6475DAB117BE5F8E9AB0Bgsmacom_-- From nobody Tue Oct 20 19:01:17 2015 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 B85D01B2C9E for ; Tue, 20 Oct 2015 19:01:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021020114.31127.75170.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 19:01:14 -0700 From: IETF Secretariat Archived-At: Subject: [Slim] Milestones changed for slim WG X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 02:01:14 -0000 Changed milestone "Submit "Multiple Language Content Type" to the IESG (based on draft-tomkinson-slim-multilangcontent)", set due date to March 2016 from November 2015. URL: https://datatracker.ietf.org/wg/slim/charter/ From nobody Tue Oct 20 19:02:34 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BA31B2CA4; Tue, 20 Oct 2015 19:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN0s2mQwqU8B; Tue, 20 Oct 2015 19:02:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0669.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::669]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FEF1B2CA2; Tue, 20 Oct 2015 19:02:30 -0700 (PDT) Received: from DB5PR04MB1029.eurprd04.prod.outlook.com (10.161.199.143) by DB5PR04MB1031.eurprd04.prod.outlook.com (10.161.199.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Wed, 21 Oct 2015 02:02:12 +0000 Received: from DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) by DB5PR04MB1029.eurprd04.prod.outlook.com ([10.161.199.143]) with mapi id 15.01.0300.010; Wed, 21 Oct 2015 02:02:12 +0000 From: Natasha Rooney To: Nik Tomkinson Thread-Topic: [Slim] WG Action: Formed Selection of Language for Internet Media (slim) Thread-Index: AQHRCDM1pZjmkusGekOpLHOkd3wuS55zMHWAgAIIIgA= Date: Wed, 21 Oct 2015 02:02:12 +0000 Message-ID: <486F7860-B27D-4309-8A1C-D54EC7D8404F@gsma.com> References: <20151016165330.12818.19572.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [219.108.220.186] x-microsoft-exchange-diagnostics: 1; DB5PR04MB1031; 5:QMOQeaLyXkuuSEFBAFIDFjprhvk4edxxA+4jzR2NGYih8n37RqNd7m+saVnkSRitHMBs6onfh+c9yGZcruisbLBy9tUDXthyQwat4N6CaGHJNd+bokVuneeLZ4WDjx3awVyxej9UGeQOl4kW8mLX8Q==; 24:JdyaMLH2Ko93JZ6oyu5uLSozfSyaRVSGPgn2rtXIcjgUZYf7SK/U7yBQcUrqLD7T/Dwq1pKWat/SvkCZzja/OrUGwO99GvVRor2PdQoIuyg=; 20:gpp0JVQoxO/CFpOzNV69GktqX1Ll67UZhHCPsStRYKCJp9xUq+OZ+q4nGNQX1t+CvN0SJdjMIcq87Ox7bpE+bQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1031; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001); SRVR:DB5PR04MB1031; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1031; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(189002)(377454003)(24454002)(110136002)(97736004)(189998001)(5008740100001)(122556002)(19617315012)(81156007)(86362001)(33656002)(5004730100002)(92566002)(36756003)(40100003)(2950100001)(2900100001)(5890100001)(82746002)(11100500001)(50986999)(64706001)(102836002)(66066001)(83716003)(16236675004)(76176999)(46102003)(77096005)(5001960100002)(5002640100001)(15975445007)(5007970100001)(105586002)(106116001)(57306001)(106356001)(19580405001)(87936001)(50226001)(19580395003)(101416001)(10400500002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1031; H:DB5PR04MB1029.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_486F7860B27D43098A1CD54EC7D8404Fgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 02:02:12.4910 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1031 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DB5PR04MB1029.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 219.108.220.186 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: DB5PR04MB1031.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" , "slim-chairs@ietf.org" Subject: Re: [Slim] WG Action: Formed Selection of Language for Internet Media (slim) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 02:02:33 -0000 --_000_486F7860B27D43098A1CD54EC7D8404Fgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 20, 2015, at 4:00 AM, Nik Tomkinson > wrote: I mentioned this off list to Randall, but the Milestone for draft-tomkinson= -slim-multilangcontent needs to be updated to Mar 2016 draft-gellens-slim-negotiating-human-language-02 is now set to Mar 2016. https://datatracker.ietf.org/wg/slim/documents/ Thanks! This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_486F7860B27D43098A1CD54EC7D8404Fgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <75AD77BFCEA2234C9AAE40F9DAE851AE@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

draft-gellens-slim-negotiating-human-language-02  is now set to M= ar 2016.

Thanks!

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

--_000_486F7860B27D43098A1CD54EC7D8404Fgsmacom_-- From nobody Tue Oct 20 19:10:36 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3711B2CD6 for ; Tue, 20 Oct 2015 19:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nJ_Uz6l-0HE for ; Tue, 20 Oct 2015 19:10:33 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DB31B2CD7 for ; Tue, 20 Oct 2015 19:10:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,709,1437436800"; d="scan'208";a="344751510" Received: from sea3-co-svc-lb3-vlan2.amazon.com (HELO email-inbound-relay-60010.pdx1.amazon.com) ([172.18.12.82]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2015 02:10:28 +0000 Received: from ex10-hub-7002.ant.amazon.com (pdx1-ws-svc-lb16-vlan2.amazon.com [10.239.138.210]) by email-inbound-relay-60010.pdx1.amazon.com (8.14.7/8.14.7) with ESMTP id t9L2AKZv013463 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Oct 2015 02:10:28 GMT Received: from EX13D08UWC003.ant.amazon.com (10.43.162.21) by ex10-hub-7002.ant.amazon.com (10.43.110.153) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 20 Oct 2015 19:10:07 -0700 Received: from EX13D08UWC002.ant.amazon.com (10.43.162.168) by EX13D08UWC003.ant.amazon.com (10.43.162.21) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 21 Oct 2015 02:10:06 +0000 Received: from EX13D08UWC002.ant.amazon.com ([10.43.162.168]) by EX13D08UWC002.ant.amazon.com ([10.43.162.168]) with mapi id 15.00.1076.000; Wed, 21 Oct 2015 02:10:06 +0000 From: "Phillips, Addison" To: "slim@ietf.org" Thread-Topic: draft-tomkinson comments Thread-Index: AdELTrh+5ACkV0fPQwCl29/LH/86jg== Date: Wed, 21 Oct 2015 02:10:06 +0000 Message-ID: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> 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.235] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: [Slim] draft-tomkinson comments X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 02:10:35 -0000 SGksDQoNCkFzIHByb21pc2VkLCBhIG51bWJlciBvZiBjb21tZW50cyBvbiB0aGUgY3VycmVudCBk cmFmdC10b21raW5zb24gZm9sbG93IG15IC5zaWcuIENvbW1lbnRzIGFyZSBsYWJlbGVkIGJ5IHNl Y3Rpb24gaW4gdGhlIGRvY3VtZW50Lg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUGhpbGxpcHMNClBy aW5jaXBhbCBTREUsIEkxOE4gQXJjaGl0ZWN0IChBbWF6b24pDQpDaGFpciAoVzNDIEkxOE4gV0cp DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNo aXRlY3R1cmUuDQoNCj09PT09DQoNCg0KQWJzdHJhY3Q6IFRoZSB0ZXJtICJsYW5ndWFnZSBjb2Rl IiBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGUgdGVybSAibGFuZ3VhZ2UgdGFnIi4gSXQncyBo ZWxwZnVsIHRvIGJlIGNvbnNpc3RlbnQgdG8gYXZvaWQgY29uZnVzaW5nIHdpdGggSVNPIHN0YW5k YXJkIGVsZW1lbnRzICh3aGljaCBhcmUgZ2VuZXJhbGx5IHJlZmVycmVkIHRvIGFzICdjb2Rlcycp IGFuZCB0byBhZG9wdCB0aGUgc2FtZSB0ZXJtaW5vbG9neSBhcyBCQ1AgNDcuDQoNCjMuMSBIZWFs dGggd2FybmluZzogdGhlIGV4cGxhbmF0b3J5IHNlY3Rpb24gbWF5IG5lZWQgdG8gdXNlIGRpZmZl cmVudCBzY3JpcHRzIHRvIGhhbmRsZSBhbGwgb2YgdGhlIGxhbmd1YWdlcy4gVGhpcyBzdWdnZXN0 cyB0aGF0IHRoZSBleHBsYW5hdG9yeSBibG9jayBzaG91bGQgdXNlIHRoZSBVVEYtOCBlbmNvZGlu Zy4gQSBoZWFsdGggd2FybmluZyBhYm91dCBjaGFyYWN0ZXIgZW5jb2RpbmdzIGFuZCB0aGUgcmVj b21tZW5kYXRpb24gZm9yIHVzaW5nIFVURi04IHdvdWxkIGJlIHVzZWZ1bCBpZiBpbmNsdWRlZCBo ZXJlPw0KDQozLjEgImxhbmd1YWdlIChvciBsb2NhbGUpIjogdGhlIHRlcm0gbG9jYWxlIGlzIHVu bmVjZXNzYXJ5IGhlcmUsIHVubGVzcyB5b3Ugd2FudCB0byBleHBsYWluIHRoYXQgdGhlIGxhbmd1 YWdlIG1pZ2h0IGJlIGRlcml2ZWQgZnJvbSB0aGUgZW5kLXVzZXIncyBsb2NhbGUuIFNob3VsZCB0 aGVyZSBiZSBhIHRlcm1pbm9sb2d5IHNlY3Rpb24/IFczQyBpcyB3b3JraW5nIG9uIGEgZG9jdW1l bnQgdGhhdCBkZWZpbmVzIHNvbWUgb2YgdGhlc2UsIGJ1dCBpdCBpcyBub3QgbWF0dXJlIGVub3Vn aCB0byBzZXJ2ZSBhcyBhIHJlZmVyZW5jZSAoaHR0cDovL3d3dy53My5vcmcvVFIvbHRsaS8pLiBV bmljb2RlIFRSIDM1IHRhbGtzIGFib3V0IHRoZSBzYW1lIGlzc3VlOiB0aGF0IGxhbmd1YWdlcyBh bmQgbG9jYWxlcyBhcmUgZnVuZGFtZW50YWxseSByZWxhdGVkIGFuZCB0aGF0IHlvdSBjYW4sIGlu IG1hbnkgY2FzZXMgKHN1Y2ggYXMgdGhpcyBvbmUpIGlnbm9yZSB0aGUgbG9jYWxlIGNvbmNlcHQu DQoNCjMuMiAibGFuZ3VhZ2UgbWVzc2FnZSBwYXJ0cyBhcmUgdHJhbnNsYXRpb25zIG9mIHRoZSBz YW1lIG1lc3NhZ2UiIFRoaXMgcHJlc3VtZXMgdGhhdCB0aGV5IGFyZSB0cmFuc2xhdGlvbnMuIFRo ZXkgbWlnaHQgbm90IGJlIGV4YWN0IHRyYW5zbGF0aW9ucyBhbmQgbWlnaHQgbm90IGJlIGV4YWN0 bHkgdGhlIHNhbWUuIFdoaWxlIHRoZSAqaW50ZW50aW9uKiBvZiB0aGUgZG9jdW1lbnQgaXMgdGhh dCB0aGV5IGFyZSB0cmFuc2xhdGlvbnMsIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSBvZiBzdWNoLiBQ ZXJoYXBzICIuLi5hcmUgdXN1YWxseSB0cmFuc2xhdGlvbnMuLi4iDQoNCjMuMiBUaGUgcmVjb21t ZW5kYXRpb24gdG8gYXBwbHkgYSAnTmFtZScgIHBhcmFtZXRlciBraW5kIG9mIHByZXN1bWVzIHRo YXQgdGhlIG5hbWUgaXMgbWVhbmluZ2Z1bCBpbiBBU0NJSSwgc2luY2UgdGhpcyBpcyBhbiBoZWFk ZXIgZmllbGQgYW5kIFFQIG9yIE1JTUUgZW5jb2Rpbmcgd29uJ3QgYmUgYW55dGhpbmcgYnV0IGEg YnVuY2ggb2YgZ2liYmVyaXNoLiBSZW5kZXJpbmcgaW50byBBU0NJSSBvciBpbnRvIEVuZ2xpc2gg aXMgbm90IHZlcnkgaW50ZXJuYXRpb25hbCBmcmllbmRseSBhbmQgaGF2aW5nIHRoZSBleGFtcGxl IGJlICdlbmdsaXNoLnR4dCcgaXMgaWdub3JpbmcgdGhlIHByb2JsZW0/DQoNCjMuMyBUaGUgdW5t YXRjaGVkIG1lc3NhZ2UgcGFydCBzZWVtcyBwcm9ibGVtYXRpYyB0byBtZS4gSXQgcmVxdWlyZXMg dGhlIHNlbmRlciB0byBwcm92aWRlIGEgdmVyc2lvbiBvZiB0aGUgbWVzc2FnZSAoaW5jcmVhc2lu ZyBtZXNzYWdlIHNpemUtLXNvbWUgc3lzdGVtcyBoYXZlIHNpemUgbGltaXRzISkgdGhhdCB3aWxs IGJlIHNob3duIHdoZW4gbGFuZ3VhZ2UgbmVnb3RpYXRpb24gZmFpbHMsIHJhdGhlciB0aGFuIGFs bG93aW5nIG9uZSBvZiB0aGUgYWxyZWFkeSBleHRhbnQgc2VjdGlvbnMgdG8gYmUgc2VsZWN0ZWQg YXMgdGhlIGRlZmF1bHQuIFRoZXJlIGlzIGFscmVhZHkgYSBwcmVhbWJsZSBzZWN0aW9uIGZvciBj YXNlcyB0aGF0IG11bHRpcGFydC9tdWx0aWxpbmd1YWwgaXMgbm90IHN1cHBvcnRlZC4gQW5kIHRo ZSB1bm1hdGNoZWQgbWVzc2FnZSAocHJvYmFibHkgZmFsc2VseSkgYWZmZWN0cyBhIHBvc2Ugb2Yg aGF2aW5nICJubyBsYW5ndWFnZSIuIFdoeSBub3QgYWxsb3cgb25lIG9mIHRoZSBsYW5ndWFnZSBi ZWFyaW5nIHNlY3Rpb25zIGJlIHRhZ2dlZCBhcyB0aGUgImRlZmF1bHQiIG1lc3NhZ2U/IElmIGEg c2VuZGVyIHdpc2hlcyB0byBtYWtlIHRoZSAiZGVmYXVsdCIgKHVubWF0Y2hlZCkgbWVzc2FnZSBi ZSBsYW5ndWFnZSBuZXV0cmFsIHNvbWVob3csIHRoZXkgY2FuIHRhZyBpdCB1c2luZyBhIHRhZyBw cm92aWRlZCBmb3IgdGhhdCBwdXJwb3NlLCBzdWNoIGFzIHp4eCBvciB1bmQuDQoNCkFsdGVybmF0 aXZlbHksIHdoeSBub3QgdXNlIHRoZSBQcmVmYWNlIHNlY3Rpb24/IElmIHRoZSBlbmQgdXNlciB3 YW50cyB0byByZWFkIHRoZSBtZXNzYWdlLCBwcmVzdW1hYmx5IHRoZXkgd2lsbCBuZWVkIHRvIGNo b29zZSBvbmUgb2YgdGhlIGxhbmd1YWdlcyB0byBkbyBpdCBpbi4NCg0KNC4gVGhpcyBzZWN0aW9u IGlzIGludHJvZHVjZWQ6DQoNCi0tDQogICBUaGUgbG9naWMgZm9yIHNlbGVjdGluZyB0aGUgbWVz c2FnZSBwYXJ0IHRvIHJlbmRlciBhbmQgcHJlc2VudCB0byB0aGUNCiAgIHJlY2lwaWVudCBpcyBx dWl0ZSBzdHJhaWdodGZvcndhcmQgYW5kIGlzIHN1bW1hcmlzZWQgaW4gdGhlIG5leHQgZmV3DQog ICBwYXJhZ3JhcGhzLg0KLS0NCg0KSXQgc2VlbXMgaHlwZXJib2xpYyB0byBzYXkgInF1aXRlIHN0 cmFpZ2h0Zm9yd2FyZCIuIEVsaW1pbmF0ZSB0aGF0IHBocmFzZT8NCg0KNC4gVGhlIHNlY3Rpb24g c2F5czoNCg0KLS0NCi4uLnNlbGVjdCB0aGUgYmVzdCBtYXRjaCBmb3INCiAgIHRoZSB1c2VyJ3Mg cHJlZmVycmVkIGxhbmd1YWdlIGZyb20gdGhlIGxhbmd1YWdlIG1lc3NhZ2UgcGFydHMNCiAgIGF2 YWlsYWJsZQ0KLS0NCg0KQnV0IGRlc2NyaWJlcyB0aGF0IGFzOg0KDQotLQ0KVGhlIHNlbGVjdGlv biBvZiBsYW5ndWFnZSBwYXJ0IG1heSBiZSBpbXBsZW1lbnRlZCBpbiBhDQogICB2YXJpZXR5IG9m IHdheXMgYW5kIGlzIGEgbWF0dGVyIGZvciB0aGUgZW1haWwgY2xpZW50IGFuZCBpdHMgdXNlcg0K ICAgcHJlZmVyZW5jZXMuDQotLQ0KDQpJc24ndCB0aGlzIHRoZSBudWIgb2YgdGhlIHByb2JsZW0/ IEkga25vdyB0aGF0LCBmb3IgZXhhbXBsZSwgTWFyayBEYXZpcyBzdWdnZXN0cyB0aGF0IHNvbWUg Y2xpZW50cyBtYXkgd2lzaCB0byB1c2UgbW9yZSBjb21wbGV4IG9yIGhlbHBmdWwgbWF0Y2hpbmcg c2NoZW1lcyB0aGFuIHRob3NlIGRlZmluZWQgaW4gQkNQIDQ3ICh3aGljaCBhcmUgcHJldHR5IHNp bXBsaXN0aWMpLiBXZSBkb24ndCBoYXZlIHRvIGZvcmJpZCBzb21ldGhpbmcgbW9yZSBlbGVnYW50 LiBCdXQgZnVuZGFtZW50YWwgbWF0Y2hpbmcgaXMgaW1wcm92ZWQgaWYgdGhlcmUgYXJlIHNvbWUg YmFzZSByZWNvbW1lbmRhdGlvbnMuDQoNCg0KNC4gVGhlcmUgaXMgYSBub3RlIGFib3V0IHRoZSBz dWJqZWN0IGxpbmU6DQoNCi0tDQpTaW1pbGFybHksIHRoZSBzdWJqZWN0IHRvIGRpc3BsYXkgKGZv ciBleGFtcGxlIGluIGENCiAgIG1lc3NhZ2UgbGlzdGluZykgc2hvdWxkIGJlIGNob3NlbiBmcm9t IHRoZSBzZWxlY3RlZCBsYW5ndWFnZSBtZXNzYWdlDQogICBwYXJ0IGlmIGl0IGlzIGF2YWlsYWJs ZS4NCi0tDQoNCkFuZCBzbGlnaHRseSBsYXRlcjoNCg0KLS0NClRoZSB0b3AtbGV2ZWwgU3ViamVj dCBoZWFkZXIgZmllbGQgdmFsdWUgc2hvdWxkIGJlIHVzZWQNCiAgIHdoZW5ldmVyIGEgc3VpdGFi bGUgdHJhbnNsYXRpb24gY2Fubm90IGJlIGlkZW50aWZpZWQuDQotLQ0KDQpUaGVzZSByZXF1aXJl bWVudHMgc2hvdWxkIGJlIHB1bGxlZCB0b2dldGhlciBhbmQgbWFkZSBjb25zaXN0ZW50LiBJbiBw YXJ0aWN1bGFyLCB0aGUgbWVzc2FnZSBuZWVkcyB0byBoYXZlIGEgU3ViamVjdCBldmVuIGlmIHRo ZSAic2VsZWN0ZWQgdHJhbnNsYXRpb25zIiBkb2VzIG5vdC4gDQoNCjUuIFRoZXJlIGlzIHRoaXMg cmVjb21tZW5kYXRpb246DQoNCi0tDQpXaGlsZSBSRkMgNTY0NiBwcm92aWRlcyBhIG1lY2hhbmlz bSBhY2NvbW1vZGF0aW5nDQogICBpbmNyZWFzaW5nbHkgZmluZS1ncmFpbmVkIGRpc3RpbmN0aW9u cywgaW4gdGhlIGludGVyZXN0IG9mIG1heGltdW0NCiAgIGludGVyb3BlcmFiaWxpdHksIGVhY2gg Q29udGVudC1MYW5ndWFnZSB2YWx1ZSBTSE9VTEQgYmUgcmVzdHJpY3RlZCB0bw0KICAgdGhlIGxh cmdlc3QgZ3JhbnVsYXJpdHkgb2YgbGFuZ3VhZ2UgdGFnczsgaW4gb3RoZXIgd29yZHMsIGl0IGlz DQogICBSRUNPTU1FTkRFRCB0byBzcGVjaWZ5IG9ubHkgYSBQcmltYXJ5LXN1YnRhZyBhbmQgTk9U IHRvIGluY2x1ZGUNCiAgIHN1YnRhZ3MgKGUuZy4sIGZvciByZWdpb24gb3IgZGlhbGVjdCkgdW5s ZXNzIHRoZSBsYW5ndWFnZXMgbWlnaHQgYmUNCiAgIG11dHVhbGx5IGluY29tcHJlaGVuc2libGUg d2l0aG91dCB0aGVtLg0KLS0NCg0KSSB0aGluayB0aGlzIHRleHQgaXMgcG90ZW50aWFsbHkgaGFy bWZ1bCwgYXMgaXQgbWlnaHQgaW50ZXJmZXJlIHdpdGggdGhlIG5lZWRzIG9mIHNlbmRlcnMgYW5k IGNsaWVudHMgdG8gZGlzdGluZ3Vpc2ggdGV4dCBiYXNlZCBvbiBhIHZhcmlldHkgb2YgZmFjdG9y cyBhbmQgaWdub3JlcyB0aGUgZmFjdCB0aGF0IHNvbWUgbGFuZ3VhZ2UgdmFyaWF0aW9uIGlzIG5v dCBtdXR1YWxseSBjb21wcmVoZW5zaWJsZSBhdCB0aGUgcHJpbWFyeSBsYW5ndWFnZSBsZXZlbC4g DQoNCkFuIGltcGxlbWVudGF0aW9uIHJlc3RyaWN0aW9uIHRvIHRoZSBwcmltYXJ5IGxhbmd1YWdl IHN1YnRhZyB3b3VsZCBiZSBhIGRpc2FkdmFudGFnZSB0byBsYW5ndWFnZXMgdGhhdCBoYXZlIGlt cG9ydGFudCBzY3JpcHQsIHJlZ2lvbiwgb3Igb3RoZXIgdmFyaWF0aW9ucyBzdWNoIGFzIGV4dGxh bmcgb3IgdmFyaWFudC4gQkNQIDQ3IGhhcyBhIHdob2xlIHNlY3Rpb24gKGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2JjcDQ3I3NlY3Rpb24tNC4xKSBhYm91dCB0aGUgY2hvaWNlIG9mIGxhbmd1 YWdlIHRhZyB0aGF0IGJhc2ljYWxseSByZWNvbW1lbmRzIHNpbWlsYXIgdGhpbmdzIGFuZCBJIHVu ZGVyc3RhbmQgd2h5IGl0J3MgaW1wb3J0YW50IGZvciBzZW5kZXJzIG5vdCB0byBhZGQgdW5uZWNl c3Nhcnkgc3VidGFncy4gQnV0IEkgdGhpbmsgeW91J2QgYmUgYmV0dGVyIG9mZiBub3QgaGF2aW5n IHF1aXRlIHNvIG11Y2ggbm9ybWF0aXZlIGxhbmd1YWdlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBh bmQgYSBtb3JlIGZvY3VzZWQgcmVjb21tZW5kYXRpb24gdGhhdCBkb2VzIG5vdCBpbXBpbmdlIG9u IHRoZSBuZWVkcyBvZiBzZW5kZXJzIGFuZCBjbGllbnRzIHRvIHByb3ZpZGUgYWRlcXVhdGUgbGFu Z3VhZ2UgaW5mb3JtYXRpb24uIA0KDQo3LiBJU08gODg1OS0xPyBIb3cgYWJvdXQgdXNpbmcgdGhl IFVURi04IGVuY29kaW5nIGluc3RlYWQ/DQoNClNob3VsZCB0aGUgZG9jdW1lbnQgcG9pbnQgb3V0 IGhlcmUgdGhhdCBlYWNoIGV4YW1wbGUgU3ViamVjdCBmaWVsZCBpcyBpbiBhIHNlcGFyYXRlIG11 bHRpcGFydC9tdWx0aWxpbmd1YWwgYmxvY2s/DQoNCg0K From nobody Mon Oct 26 23:38:10 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9B81A0372; Mon, 26 Oct 2015 23:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXaJHGVELZbl; Mon, 26 Oct 2015 23:38:07 -0700 (PDT) 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 607B71A036C; Mon, 26 Oct 2015 23:38:04 -0700 (PDT) Received: by vkfw189 with SMTP id w189so113933625vkf.2; Mon, 26 Oct 2015 23:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=xOcqSVU8cq9aKm3zruR530Hd1Uv/uou+1RFPgY8px6Y=; b=sTqHsJSFXhBz4JkDflF9RCDnBoFj0qnaY9vF9b2h70S/+CLIwuJIfPM95TdV45O21A 4iMYgsblc2pC+LvStOaw191jH2iQgX166yvVtNBIoYGiPvKkD7E5MjtYI71nggRMJprS Ip6k7fVhxBxldiUY757xX+pQjq5QfrunP92OtAMDFrXrn0ESz+E84Ds+Z29ls/8Z7cpp 9ruqpA7MjhAwVJZvYVEkA50JyOSYxZ5oEbT+kHa/MjKKmB5vS0aP+JzrGNEGu6CyvWun ghwg05+tsZ1p7Ckk66T1vYFcrgcnS3dYHulHlfWiTL85N0cg78Fnou0YAZFgKBUbRa8a 25Ig== MIME-Version: 1.0 X-Received: by 10.31.14.7 with SMTP id 7mr1311212vko.133.1445927883533; Mon, 26 Oct 2015 23:38:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Mon, 26 Oct 2015 23:38:03 -0700 (PDT) Date: Tue, 27 Oct 2015 07:38:03 +0100 X-Google-Sender-Auth: v6rAF97-a8FlzjeTa7wq_--7KOU Message-ID: From: Barry Leiba To: core-chairs@ietf.org, dbound-chairs@ietf.org, lager-chairs@ietf.org, slim@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Slim] No working group session agendas posted yet X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 06:38:08 -0000 Hey, chairs, We're past the time for posting session agendas, and you four working groups don't yet have agendas posted. For slim, there's a reason: we got the working group chartered very late in the process. Still, please try to post an agenda ASAP. For the others, please do the same... or let me know if this means you don't need the session after all. Barry From nobody Tue Oct 27 01:16:46 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BF21B37D4 for ; Tue, 27 Oct 2015 01:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDsqDNryFEzE for ; Tue, 27 Oct 2015 01:16:27 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0680.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::680]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25681B37D5 for ; Tue, 27 Oct 2015 01:15:54 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 08:15:32 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 08:15:32 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: IETF94 Agenda: please review! Thread-Index: AQHREI+mcCjch7iTKkWwY1EAWM8IRA== Date: Tue, 27 Oct 2015 08:15:32 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2400:4040:0:23:1540:7b99:d5fb:8af1] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1033; 5:x7HDdf5i7r0T2308/DS4vbPuMWQ0m10TqQeoXDnKa4FbxwA2Teo6bLbS1/E+0BNkI3BcjNT+9w/XiZ+ZfO0MPiY+vSebSSLToEhOMujM5l5jag4mFHnwE60B8Mf6dMMxLagly866nIyvhierwyNLyA==; 24:CCduwDINIZtQcdVsRoW93wS2rHUEaPXVT2mH9x9CAUCUvhOKNovLtroXcZpccqHuvgAotx3MtU5Tyf8+blKCLJX3MurGckxMmFreIYIu83Y=; 20:W583NZOh/xyfLWk8XvPK3ycZnWPTPdsdAKlJ6Iy/uDjHU4k7C7Dg+SDtTLR675fZfoakZkTGFFy+f27TK/AVlg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1033; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(102215026); SRVR:HE1PR04MB1033; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1033; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(69234005)(53754006)(189002)(229853001)(19580405001)(5890100001)(92566002)(19580395003)(105586002)(106356001)(2351001)(106116001)(101416001)(2900100001)(50226001)(5008740100001)(82746002)(57306001)(81156007)(122556002)(97736004)(5001960100002)(86362001)(5002640100001)(10400500002)(2501003)(77096005)(15975445007)(110136002)(189998001)(102836002)(16236675004)(5004730100002)(87936001)(36756003)(11100500001)(5007970100001)(83716003)(50986999)(33656002)(19617315012)(226693001)(40100003)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1033; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FD7A99AF4F494D66A6D2B251F2DBB9A5gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 08:15:32.4426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1033 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2400:4040:0:23:1540:7b99:d5fb:8af1 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1033.eurprd04.prod.outlook.com Archived-At: Cc: Barry Leiba Subject: [Slim] IETF94 Agenda: please review! X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 08:16:31 -0000 --_000_FD7A99AF4F494D66A6D2B251F2DBB9A5gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all! We are overdue to publish our agenda for the meeting next week. This is the= proposed agenda, please let us know if you wish to add, remove or have any= thing changed! FYI I have still to go through the comments from Addison, and once I have d= one this (tomorrow!) there may be some minor changes to the agenda. Thanks all! Natasha MONDAY, November 2, 2015 17:10 - 19:10 Afternoon Session III Room 301 SLIM Selection of Language for Internet Media WG Chairs: Bernard Aboba, Natasha Rooney WG Datatracker Web Page: http://datatracker.ietf.org/wg/slim/charter/ Welcome and Introductions to the Chairs Natasha Rooney 10 mins Agenda Bashing Natasha Rooney 5 mins Charter and Use Case Review Bernard Aboba 20 mins Proposed Work Items Section Introduction Natasha Rooney 5 mins Proposed Work Items: Negotiating Human Language in Real-Time Communications draft-gellens-slim-negotiating-human-language-02 Randall Gellens (NOT CONFIRMED) 20 mins Proposed Work Items: Multiple Language Content Type draft-tomkinson-slim-multilangcontent-02 Nik Tomkinson or Nathaniel Borenstein (NOT CONFIRMED) 20 mins Other Possible Work Items Bernard Aboba 15 mins Work Methods and Group Management Natasha Rooney 15 mins Overflow Time 10mins Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_FD7A99AF4F494D66A6D2B251F2DBB9A5gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4B8351C478532A46838D46DDC65BA04D@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi all!

We are overdue to publish our agenda for the meeting next w= eek. This is the proposed agenda, please let us know if you wish to add, re= move or have anything changed!

FYI I have still to go through the comments from Addison, a= nd once I have done this (tomorrow!) there may be some minor changes to the= agenda. 

Thanks all!

Natasha



MONDAY, November 2, 2015
17:10 - 19:10 Afternoon Session III

Room 301 SLIM Selection of Language for Internet Media WG

Chairs: Bernard Aboba, Natasha Rooney

WG Datatracker Web Page: http://datatracker.ietf.org/wg/= slim/charter/

Welcome and Introductions to the Chairs
Natasha Rooney
10 mins

Agenda Bashing
Natasha Rooney
5 mins

Charter and Use Case Review
Bernard Aboba
20 mins

Proposed Work Items Section Introduction
Natasha Rooney
5 mins

Proposed Work Items: Negotiating Human Language in Rea= l-Time Communications
draft-gellens-slim-negotiating-human-language-02
Randall Gellens (NOT CONFIRMED)
20 mins

Proposed Work Items: Multiple Language Content Type
draft-tomkinson-slim-multilangcontent-02
Nik Tomkinson or Nathaniel Borenstein (NOT CONFIR= MED)
20 mins

Other Possible Work Items
Bernard Aboba
15 mins

Work Methods and Group Management
Natasha Rooney
15 mins

Overflow Time
10mins 





Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


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

--_000_FD7A99AF4F494D66A6D2B251F2DBB9A5gsmacom_-- From nobody Tue Oct 27 02:52:05 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA81A6F6D for ; Tue, 27 Oct 2015 02:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCdicYTrFFKT for ; Tue, 27 Oct 2015 02:52:00 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8DF1A6F66 for ; Tue, 27 Oct 2015 02:52:00 -0700 (PDT) Received: by lbbwb3 with SMTP id wb3so59187132lbb.1 for ; Tue, 27 Oct 2015 02:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f3W3mJx6pRyVBD7wrxrOUIHaVGHjeNlf+ezRSHCy300=; b=a5bs649k5H9YKrQOvpgx+Yk6A4s3Z1bJBmf1QURB0HVLxbSnEpxdUwcyL33yNqI7Jv aLJlECjjQpT7MfRZIFG2o817eCtvHKWh9NK4uc0H99K5CUztP3BTmQmwY6lxyf4QDAKq WsypBUJ+UqqeJbSrFF7Ym1Zb8CWMYK4t6iXs206MJinVDFYovFvgnq0FE5VQUDQHzWBG vXKPYJfpVjPNEPFd+aoaaF0mG4w9/hYrQF90gDul6th648O3ndyp8cOzXfXmoKXqZTQC yS6JXGB8MTUjFBG7fTaT99dBz4vefotwsVIzxjEEhnpo5bUQufrwQeXQozYiA7sys8VI wUUA== MIME-Version: 1.0 X-Received: by 10.112.157.195 with SMTP id wo3mr19686547lbb.0.1445939518176; Tue, 27 Oct 2015 02:51:58 -0700 (PDT) Received: by 10.112.13.72 with HTTP; Tue, 27 Oct 2015 02:51:58 -0700 (PDT) In-Reply-To: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> References: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> Date: Tue, 27 Oct 2015 09:51:58 +0000 Message-ID: From: Nik Tomkinson To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=001a11c3274a5901510523130774 Archived-At: Cc: "slim@ietf.org" Subject: Re: [Slim] draft-tomkinson comments X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:52:03 -0000 --001a11c3274a5901510523130774 Content-Type: text/plain; charset=UTF-8 Thanks very much for the extensive comments. I am working through them now and should have responses for you in the next day or so. Nik. On 21 October 2015 at 03:10, Phillips, Addison wrote: > Hi, > > As promised, a number of comments on the current draft-tomkinson follow my > .sig. Comments are labeled by section in the document. > > Addison > > Addison Phillips > Principal SDE, I18N Architect (Amazon) > Chair (W3C I18N WG) > > Internationalization is not a feature. > It is an architecture. > > ===== > > > Abstract: The term "language code" should be replaced with the term > "language tag". It's helpful to be consistent to avoid confusing with ISO > standard elements (which are generally referred to as 'codes') and to adopt > the same terminology as BCP 47. > > 3.1 Health warning: the explanatory section may need to use different > scripts to handle all of the languages. This suggests that the explanatory > block should use the UTF-8 encoding. A health warning about character > encodings and the recommendation for using UTF-8 would be useful if > included here? > > 3.1 "language (or locale)": the term locale is unnecessary here, unless > you want to explain that the language might be derived from the end-user's > locale. Should there be a terminology section? W3C is working on a document > that defines some of these, but it is not mature enough to serve as a > reference (http://www.w3.org/TR/ltli/). Unicode TR 35 talks about the > same issue: that languages and locales are fundamentally related and that > you can, in many cases (such as this one) ignore the locale concept. > > 3.2 "language message parts are translations of the same message" This > presumes that they are translations. They might not be exact translations > and might not be exactly the same. While the *intention* of the document is > that they are translations, there is no guarantee of such. Perhaps "...are > usually translations..." > > 3.2 The recommendation to apply a 'Name' parameter kind of presumes that > the name is meaningful in ASCII, since this is an header field and QP or > MIME encoding won't be anything but a bunch of gibberish. Rendering into > ASCII or into English is not very international friendly and having the > example be 'english.txt' is ignoring the problem? > > 3.3 The unmatched message part seems problematic to me. It requires the > sender to provide a version of the message (increasing message size--some > systems have size limits!) that will be shown when language negotiation > fails, rather than allowing one of the already extant sections to be > selected as the default. There is already a preamble section for cases that > multipart/multilingual is not supported. And the unmatched message > (probably falsely) affects a pose of having "no language". Why not allow > one of the language bearing sections be tagged as the "default" message? If > a sender wishes to make the "default" (unmatched) message be language > neutral somehow, they can tag it using a tag provided for that purpose, > such as zxx or und. > > Alternatively, why not use the Preface section? If the end user wants to > read the message, presumably they will need to choose one of the languages > to do it in. > > 4. This section is introduced: > > -- > The logic for selecting the message part to render and present to the > recipient is quite straightforward and is summarised in the next few > paragraphs. > -- > > It seems hyperbolic to say "quite straightforward". Eliminate that phrase? > > 4. The section says: > > -- > ...select the best match for > the user's preferred language from the language message parts > available > -- > > But describes that as: > > -- > The selection of language part may be implemented in a > variety of ways and is a matter for the email client and its user > preferences. > -- > > Isn't this the nub of the problem? I know that, for example, Mark Davis > suggests that some clients may wish to use more complex or helpful matching > schemes than those defined in BCP 47 (which are pretty simplistic). We > don't have to forbid something more elegant. But fundamental matching is > improved if there are some base recommendations. > > > 4. There is a note about the subject line: > > -- > Similarly, the subject to display (for example in a > message listing) should be chosen from the selected language message > part if it is available. > -- > > And slightly later: > > -- > The top-level Subject header field value should be used > whenever a suitable translation cannot be identified. > -- > > These requirements should be pulled together and made consistent. In > particular, the message needs to have a Subject even if the "selected > translations" does not. > > 5. There is this recommendation: > > -- > While RFC 5646 provides a mechanism accommodating > increasingly fine-grained distinctions, in the interest of maximum > interoperability, each Content-Language value SHOULD be restricted to > the largest granularity of language tags; in other words, it is > RECOMMENDED to specify only a Primary-subtag and NOT to include > subtags (e.g., for region or dialect) unless the languages might be > mutually incomprehensible without them. > -- > > I think this text is potentially harmful, as it might interfere with the > needs of senders and clients to distinguish text based on a variety of > factors and ignores the fact that some language variation is not mutually > comprehensible at the primary language level. > > An implementation restriction to the primary language subtag would be a > disadvantage to languages that have important script, region, or other > variations such as extlang or variant. BCP 47 has a whole section ( > http://tools.ietf.org/html/bcp47#section-4.1) about the choice of > language tag that basically recommends similar things and I understand why > it's important for senders not to add unnecessary subtags. But I think > you'd be better off not having quite so much normative language in this > specification and a more focused recommendation that does not impinge on > the needs of senders and clients to provide adequate language information. > > 7. ISO 8859-1? How about using the UTF-8 encoding instead? > > Should the document point out here that each example Subject field is in a > separate multipart/multilingual block? > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a11c3274a5901510523130774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks very much for the extensive comments. I am working = through them now and should have responses for you in the next day or so.
Nik.

On 21 October 2015 at 03:10, Phillips, Addison <addiso= n@lab126.com> wrote:
Hi,
As promised, a number of comments on the current draft-tomkinson follow my = .sig. Comments are labeled by section in the document.

Addison

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

=3D=3D=3D=3D=3D


Abstract: The term "language code" should be replaced with the te= rm "language tag". It's helpful to be consistent to avoid con= fusing with ISO standard elements (which are generally referred to as '= codes') and to adopt the same terminology as BCP 47.

3.1 Health warning: the explanatory section may need to use different scrip= ts to handle all of the languages. This suggests that the explanatory block= should use the UTF-8 encoding. A health warning about character encodings = and the recommendation for using UTF-8 would be useful if included here?
3.1 "language (or locale)": the term locale is unnecessary here, = unless you want to explain that the language might be derived from the end-= user's locale. Should there be a terminology section? W3C is working on= a document that defines some of these, but it is not mature enough to serv= e as a reference (http://www.w3.org/TR/ltli/). Unicode TR 35 talks abo= ut the same issue: that languages and locales are fundamentally related and= that you can, in many cases (such as this one) ignore the locale concept.<= br>
3.2 "language message parts are translations of the same message"= This presumes that they are translations. They might not be exact translat= ions and might not be exactly the same. While the *intention* of the docume= nt is that they are translations, there is no guarantee of such. Perhaps &q= uot;...are usually translations..."

3.2 The recommendation to apply a 'Name'=C2=A0 parameter kind of pr= esumes that the name is meaningful in ASCII, since this is an header field = and QP or MIME encoding won't be anything but a bunch of gibberish. Ren= dering into ASCII or into English is not very international friendly and ha= ving the example be 'english.txt' is ignoring the problem?

3.3 The unmatched message part seems problematic to me. It requires the sen= der to provide a version of the message (increasing message size--some syst= ems have size limits!) that will be shown when language negotiation fails, = rather than allowing one of the already extant sections to be selected as t= he default. There is already a preamble section for cases that multipart/mu= ltilingual is not supported. And the unmatched message (probably falsely) a= ffects a pose of having "no language". Why not allow one of the l= anguage bearing sections be tagged as the "default" message? If a= sender wishes to make the "default" (unmatched) message be langu= age neutral somehow, they can tag it using a tag provided for that purpose,= such as zxx or und.

Alternatively, why not use the Preface section? If the end user wants to re= ad the message, presumably they will need to choose one of the languages to= do it in.

4. This section is introduced:

--
=C2=A0 =C2=A0The logic for selecting the message part to render and present= to the
=C2=A0 =C2=A0recipient is quite straightforward and is summarised in the ne= xt few
=C2=A0 =C2=A0paragraphs.
--

It seems hyperbolic to say "quite straightforward". Eliminate tha= t phrase?

4. The section says:

--
...select the best match for
=C2=A0 =C2=A0the user's preferred language from the language message pa= rts
=C2=A0 =C2=A0available
--

But describes that as:

--
The selection of language part may be implemented in a
=C2=A0 =C2=A0variety of ways and is a matter for the email client and its u= ser
=C2=A0 =C2=A0preferences.
--

Isn't this the nub of the problem? I know that, for example, Mark Davis= suggests that some clients may wish to use more complex or helpful matchin= g schemes than those defined in BCP 47 (which are pretty simplistic). We do= n't have to forbid something more elegant. But fundamental matching is = improved if there are some base recommendations.


4. There is a note about the subject line:

--
Similarly, the subject to display (for example in a
=C2=A0 =C2=A0message listing) should be chosen from the selected language m= essage
=C2=A0 =C2=A0part if it is available.
--

And slightly later:

--
The top-level Subject header field value should be used
=C2=A0 =C2=A0whenever a suitable translation cannot be identified.
--

These requirements should be pulled together and made consistent. In partic= ular, the message needs to have a Subject even if the "selected transl= ations" does not.

5. There is this recommendation:

--
While RFC 5646 provides a mechanism accommodating
=C2=A0 =C2=A0increasingly fine-grained distinctions, in the interest of max= imum
=C2=A0 =C2=A0interoperability, each Content-Language value SHOULD be restri= cted to
=C2=A0 =C2=A0the largest granularity of language tags; in other words, it i= s
=C2=A0 =C2=A0RECOMMENDED to specify only a Primary-subtag and NOT to includ= e
=C2=A0 =C2=A0subtags (e.g., for region or dialect) unless the languages mig= ht be
=C2=A0 =C2=A0mutually incomprehensible without them.
--

I think this text is potentially harmful, as it might interfere with the ne= eds of senders and clients to distinguish text based on a variety of factor= s and ignores the fact that some language variation is not mutually compreh= ensible at the primary language level.

An implementation restriction to the primary language subtag would be a dis= advantage to languages that have important script, region, or other variati= ons such as extlang or variant. BCP 47 has a whole section (http://tools.ietf.org/html/bcp47#section-4.1) about the choice of l= anguage tag that basically recommends similar things and I understand why i= t's important for senders not to add unnecessary subtags. But I think y= ou'd be better off not having quite so much normative language in this = specification and a more focused recommendation that does not impinge on th= e needs of senders and clients to provide adequate language information.
7. ISO 8859-1? How about using the UTF-8 encoding instead?

Should the document point out here that each example Subject field is in a = separate multipart/multilingual block?


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



-- 
-----------=
------------------------------------------------------
Multiple Language=
 Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/= 
----------------=
-------------------------------------------------
--001a11c3274a5901510523130774-- From nobody Wed Oct 28 13:30:15 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52801ACED6 for ; Wed, 28 Oct 2015 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2ilApFCbg7e for ; Wed, 28 Oct 2015 13:30:10 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 23A351ACECE for ; Wed, 28 Oct 2015 13:30:10 -0700 (PDT) Received: by qkgc186 with SMTP id c186so5452630qkg.0 for ; Wed, 28 Oct 2015 13:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PagP0fyo22nFVi8Zs4fb0bmJwUYjHGV1i6cLQCYzh2U=; b=x9nmvSx9rI53nwixvShk6zQtwU5K61qLeY8rtn64WUNy3KYCemWQvn7/C6FehQRlp2 0YH9hDgretuYARNzslgrUW2vPAYrHgxOJlu30lqIl6kyVQrCSlj8NxyeGpiFJn3lfzcY Cawjy9QGWXLPFxKaKDA/GG/U7ucNfdOzodRyca3J+ZfnOIEjD53SWJ3VrUjZSCF8zTzB V2UCndir8NIghBM51TGifaMjfF5v58ukx1IW9cr3WZIkQl54Jnn/qtQlK4a8NBWcoEGN lAqXU7T2IA8Mi8nQMVBNHFqGJhfxwZR9uvIv6D70Ak1YBTGaYHBZM14O2SNPjFpWWVip YlVQ== MIME-Version: 1.0 X-Received: by 10.55.78.76 with SMTP id c73mr14140433qkb.97.1446064209307; Wed, 28 Oct 2015 13:30:09 -0700 (PDT) Received: by 10.55.165.147 with HTTP; Wed, 28 Oct 2015 13:30:09 -0700 (PDT) In-Reply-To: References: <9d9f51af87d94c8caf26b1f3801c69d4@EX13D08UWC002.ant.amazon.com> Date: Wed, 28 Oct 2015 20:30:09 +0000 Message-ID: From: Nik Tomkinson To: "Phillips, Addison" , slim@ietf.org Content-Type: multipart/alternative; boundary=001a114aa28884b1b40523300fee Archived-At: Subject: Re: [Slim] draft-tomkinson comments X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 20:30:14 -0000 --001a114aa28884b1b40523300fee Content-Type: text/plain; charset=UTF-8 My responses are inline below in the [ ]: Nik. ===== Abstract: The term "language code" should be replaced with the term "language tag". It's helpful to be consistent to avoid confusing with ISO standard elements (which are generally referred to as 'codes') and to adopt the same terminology as BCP 47. [Yes, I agree - Updated] 3.1 Health warning: the explanatory section may need to use different scripts to handle all of the languages. This suggests that the explanatory block should use the UTF-8 encoding. A health warning about character encodings and the recommendation for using UTF-8 would be useful if included here? [Do you have any suggested wording regarding the 'health warning'? I'll try to get something together for the requirement and recommendation of UTF-8.] 3.1 "language (or locale)": the term locale is unnecessary here, unless you want to explain that the language might be derived from the end-user's locale. Should there be a terminology section? W3C is working on a document that defines some of these, but it is not mature enough to serve as a reference (http://www.w3.org/TR/ltli/). Unicode TR 35 talks about the same issue: that languages and locales are fundamentally related and that you can, in many cases (such as this one) ignore the locale concept. [Agreed, Locale was a legacy term in this document and has now been removed] 3.2 "language message parts are translations of the same message" This presumes that they are translations. They might not be exact translations and might not be exactly the same. While the *intention* of the document is that they are translations, there is no guarantee of such. Perhaps "...are usually translations..." [Good point, updated to "...are typically translations..."] 3.2 The recommendation to apply a 'Name' parameter kind of presumes that the name is meaningful in ASCII, since this is an header field and QP or MIME encoding won't be anything but a bunch of gibberish. Rendering into ASCII or into English is not very international friendly and having the example be 'english.txt' is ignoring the problem? [There was a small doubt in my mind about exactly this, but I thought that an acceptable workaround is for the sending email client to use the closest (or most recognised) ASCII version of the language name in the absence of a better solution. The issue is that unnamed attachments are given generated filenames (eg. ATT00001.c ) which make it hard to tell which is which and therefore difficult for the user to find the right language. This is only an issue when the message is rendered in non-conforming legacy email clients. An alternative could be the IANA language code eg. es.txt, cz.txt, it.txt etc but I don't think this is better. I am expecting the testing stage to help here.] 3.3 The unmatched message part seems problematic to me. It requires the sender to provide a version of the message (increasing message size--some systems have size limits!) that will be shown when language negotiation fails, rather than allowing one of the already extant sections to be selected as the default. There is already a preamble section for cases that multipart/multilingual is not supported. And the unmatched message (probably falsely) affects a pose of having "no language". Why not allow one of the language bearing sections be tagged as the "default" message? If a sender wishes to make the "default" (unmatched) message be language neutral somehow, they can tag it using a tag provided for that purpose, such as zxx or und. [I think there are a couple of points to address here: Firstly the multilingual preface is not related to language negotiation at all, this is for legacy MUAs that don't understand multipart/multilingual. Secondly the 'unmatched message part' is OPTIONAL and should only be used when the sender wants to provide a language-independent version (eg. an image) suitable for unmatched users. The first language message part (the first part with a Language Tag) is considered 'default' by the fact that it is the first. This means that if the default part is not considered (by the sender) to be generic enough to be understood by an unmatched language recipient then the language independent content should be provided. I think that the use of the different parts is correct but the explanation in the I-D was insufficient and misleading. I will think of some better wording for this section and include the zxx language tag in the 'unmatched/language-independent' part.] Alternatively, why not use the Preface section? If the end user wants to read the message, presumably they will need to choose one of the languages to do it in. 4. This section is introduced: -- The logic for selecting the message part to render and present to the recipient is quite straightforward and is summarised in the next few paragraphs. -- It seems hyperbolic to say "quite straightforward". Eliminate that phrase? [Yes, it has become less straightforward over time but this text remained intact, I have removed it.] 4. The section says: -- ...select the best match for the user's preferred language from the language message parts available -- But describes that as: -- The selection of language part may be implemented in a variety of ways and is a matter for the email client and its user preferences. -- Isn't this the nub of the problem? I know that, for example, Mark Davis suggests that some clients may wish to use more complex or helpful matching schemes than those defined in BCP 47 (which are pretty simplistic). We don't have to forbid something more elegant. But fundamental matching is improved if there are some base recommendations. [Good observation, I will add some text with reference to https://tools.ietf.org/html/rfc4647] 4. There is a note about the subject line: -- Similarly, the subject to display (for example in a message listing) should be chosen from the selected language message part if it is available. -- And slightly later: -- The top-level Subject header field value should be used whenever a suitable translation cannot be identified. -- These requirements should be pulled together and made consistent. In particular, the message needs to have a Subject even if the "selected translations" does not. [OK, I will add a new section to deal with Subject Selection] 5. There is this recommendation: -- While RFC 5646 provides a mechanism accommodating increasingly fine-grained distinctions, in the interest of maximum interoperability, each Content-Language value SHOULD be restricted to the largest granularity of language tags; in other words, it is RECOMMENDED to specify only a Primary-subtag and NOT to include subtags (e.g., for region or dialect) unless the languages might be mutually incomprehensible without them. -- I think this text is potentially harmful, as it might interfere with the needs of senders and clients to distinguish text based on a variety of factors and ignores the fact that some language variation is not mutually comprehensible at the primary language level. An implementation restriction to the primary language subtag would be a disadvantage to languages that have important script, region, or other variations such as extlang or variant. BCP 47 has a whole section (http://tools.ietf.org/html/bcp47#section-4.1) about the choice of language tag that basically recommends similar things and I understand why it's important for senders not to add unnecessary subtags. But I think you'd be better off not having quite so much normative language in this specification and a more focused recommendation that does not impinge on the needs of senders and clients to provide adequate language information. [Would you recommend removing this text completely or replacing it with something less restrictive but more suitable? If so do you (or does anyone else reading this) have any suggested text?] 7. ISO 8859-1? How about using the UTF-8 encoding instead? [Updated] Should the document point out here that each example Subject field is in a separate multipart/multilingual block? [This should be clear from the new selection of subject section] --001a114aa28884b1b40523300fee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My responses are inline below in the [ ]:
<= br>
Nik.
=
=3D=3D=3D=3D=3D


Abstract: The term "language code" should be replaced with the te=
rm "language tag". It's helpful to be consistent to avoid con=
fusing with ISO standard elements (which are generally referred to as '=
codes') and to adopt the same terminology as BCP 47.=C2=A0
[Y=
es, I agree - Updated]

3.1 Health warning: the explanatory section may need to use different scrip=
ts to handle all of the languages. This suggests that the explanatory block=
 should use the UTF-8 encoding. A health warning about character encodings =
and the recommendation for using UTF-8 would be useful if included here?=C2=
=A0
[Do you have any suggested wording regarding the 'health =
warning'? I'll try to get something together for the requirement an=
d recommendation of UTF-8.]

3.1 "language (or locale)": the term locale is unnecessary here, =
unless you want to explain that the language might be derived from the end-=
user's locale. Should there be a terminology section? W3C is working on=
 a document that defines some of these, but it is not mature enough to serv=
e as a reference (http://www.w3.org/=
TR/ltli/). Unicode TR 35 talks about the same issue: that languages and=
 locales are fundamentally related and that you can, in many cases (such as=
 this one) ignore the locale concept.=C2=A0
[Agreed, Locale was a=
 legacy term in this document and has now been removed]

3.2 "language message parts are translations of the same message"=
 This presumes that they are translations. They might not be exact translat=
ions and might not be exactly the same. While the *intention* of the docume=
nt is that they are translations, there is no guarantee of such. Perhaps &q=
uot;...are usually translations..."=C2=A0
[Good point, updat=
ed to "...are typically translations..."]

3.2 The recommendation to apply a 'Name'  parameter kind of presume=
s that the name is meaningful in ASCII, since this is an header field and Q=
P or MIME encoding won't be anything but a bunch of gibberish. Renderin=
g into ASCII or into English is not very international friendly and having =
the example be 'english.txt' is ignoring the problem?=C2=A0
[There was a small doubt in my mind about exactly this, but I thought th= at an acceptable workaround is for the sending email client to use the clos= est (or most recognised) ASCII version of the language name in the absence = of a better solution. The issue is that unnamed attachments are given gener= ated filenames (eg. ATT00001.c ) which make it hard to tell which is which = and therefore difficult for the user to find the right language. This is on= ly an issue when the message is rendered in non-conforming legacy email cli= ents. An alternative could be the IANA language code eg. es.txt, cz.txt, it= .txt etc but I don't think this is better. I am expecting the testing s= tage to help here.] 3.3 The unmatched message part seems problematic to me. It requires the sen= der to provide a version of the message (increasing message size--some syst= ems have size limits!) that will be shown when language negotiation fails, = rather than allowing one of the already extant sections to be selected as t= he default. There is already a preamble section for cases that multipart/mu= ltilingual is not supported. And the unmatched message (probably falsely) a= ffects a pose of having "no language". Why not allow one of the l= anguage bearing sections be tagged as the "default" message? If a= sender wishes to make the "default" (unmatched) message be langu= age neutral somehow, they can tag it using a tag provided for that purpose,= such as zxx or und.=C2=A0
[I think there are a couple of points =
to address here: Firstly the multilingual preface is not related to languag=
e negotiation at all, this is for legacy MUAs that don't understand mul=
tipart/multilingual. Secondly the 'unmatched message part' is OPTIO=
NAL and should only be used when the sender wants to provide a language-ind=
ependent version (eg. an image) suitable for unmatched users. The first lan=
guage message part (the first part with a Language Tag) is considered '=
default' by the fact that it is the first. This means that if the defau=
lt part is not considered (by the sender) to be generic enough to be unders=
tood by an unmatched language recipient then the language independent conte=
nt should be provided. I think that the use of the different parts is corre=
ct but the explanation in the I-D was insufficient and misleading. I will t=
hink of some better wording for this section and include the zxx language t=
ag in the 'unmatched/language-independent' part.]

Alternatively, why not use the Preface section? If the end user wants to re=
ad the message, presumably they will need to choose one of the languages to=
 do it in.

4. This section is introduced:

--
   The logic for selecting the message part to render and present to the
   recipient is quite straightforward and is summarised in the next few
   paragraphs.
--

It seems hyperbolic to say "quite straightforward". Eliminate tha=
t phrase?=C2=A0
[Yes, it has become less straightforward over tim=
e but this text remained intact, I have removed it.]

4. The section says:

--
...select the best match for
   the user's preferred language from the language message parts
   available
--

But describes that as:

--
The selection of language part may be implemented in a
   variety of ways and is a matter for the email client and its user
   preferences.
--

Isn't this the nub of the problem? I know that, for example, Mark Davis=
 suggests that some clients may wish to use more complex or helpful matchin=
g schemes than those defined in BCP 47 (which are pretty simplistic). We do=
n't have to forbid something more elegant. But fundamental matching is =
improved if there are some base recommendations.=C2=A0
[Good obse=
rvation, I will add some text with reference to https://tools.ietf.org/html/rfc4647]


4. There is a note about the subject line:

--
Similarly, the subject to display (for example in a
   message listing) should be chosen from the selected language message
   part if it is available.
--

And slightly later:

--
The top-level Subject header field value should be used
   whenever a suitable translation cannot be identified.
--

These requirements should be pulled together and made consistent. In partic=
ular, the message needs to have a Subject even if the "selected transl=
ations" does not.=C2=A0
[OK, I will add a new section to dea=
l with Subject Selection]

5. There is this recommendation:

--
While RFC 5646 provides a mechanism accommodating
   increasingly fine-grained distinctions, in the interest of maximum
   interoperability, each Content-Language value SHOULD be restricted to
   the largest granularity of language tags; in other words, it is
   RECOMMENDED to specify only a Primary-subtag and NOT to include
   subtags (e.g., for region or dialect) unless the languages might be
   mutually incomprehensible without them.
--

I think this text is potentially harmful, as it might interfere with the ne=
eds of senders and clients to distinguish text based on a variety of factor=
s and ignores the fact that some language variation is not mutually compreh=
ensible at the primary language level.=20

An implementation restriction to the primary language subtag would be a dis=
advantage to languages that have important script, region, or other variati=
ons such as extlang or variant. BCP 47 has a whole section (http://tools.ietf.org/html/bcp47#=
section-4.1) about the choice of language tag that basically recommends=
 similar things and I understand why it's important for senders not to =
add unnecessary subtags. But I think you'd be better off not having qui=
te so much normative language in this specification and a more focused reco=
mmendation that does not impinge on the needs of senders and clients to pro=
vide adequate language information.=C2=A0
[Would you recommend re=
moving this text completely or replacing it with something less restrictive=
 but more suitable? If so do you (or does anyone else reading this) have an=
y suggested text?]

7. ISO 8859-1? How about using the UTF-8 encoding instead?=C2=A0
=
[Updated]

Should the document point out here that each example Subject field is in a =
separate multipart/multilingual block?=C2=A0
[This should be clea=
r from the new selection of subject section]
--001a114aa28884b1b40523300fee-- From nobody Wed Oct 28 23:34:27 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390D61A8798 for ; Wed, 28 Oct 2015 23:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3ya5PVeatVE for ; Wed, 28 Oct 2015 23:34:24 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55161A8796 for ; Wed, 28 Oct 2015 23:34:23 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.306.13; Thu, 29 Oct 2015 06:34:05 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0306.003; Thu, 29 Oct 2015 06:34:05 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Agenda Thread-Index: AQHREhPPTa8LBsRsqU+RwgwiNFv4OQ== Date: Thu, 29 Oct 2015 06:34:05 +0000 Message-ID: <11FD0586-87A0-473B-BD55-4CE984CAF587@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [210.227.101.105] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:lLPgVZ7jNEcIdPbr1WjBqWz6JFXIWEjStMvVaoOMSGDHYPEUN2VmwiaczH+a/tAui5eHlu48GtuA+Yr1X2lLPeEI9wEdq+HE4jU1gpgXhq5r2maO92cH6v6jvFqVj+sopvmpL8C23E8ewW0Gsd20jw==; 24:xq5SmQPU8dBKEAZNlWHRb04KS0GRXefOnsW6Oam1+1wf1olve7HBWSPdoFnbYGbg86imkNEMdHC4Flm+HiFkpLfacIIh0+JSQOl8+BPXgdg=; 20:nXyacgH/IecmRbN6bRrQ2/9XFSO9awKMHatVvuPEagwwY7ExBnLk8WqtP3/9O6Llao+quSBGxv0Kc1y9JEZszA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(102215026); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 0744CFB5E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(189002)(53754006)(189998001)(10400500002)(77096005)(2900100001)(106116001)(110136002)(229853001)(16236675004)(11100500001)(92566002)(5007970100001)(15975445007)(81156007)(102836002)(33656002)(107886002)(5001960100002)(5890100001)(2501003)(122556002)(36756003)(106356001)(105586002)(5004730100002)(5002640100001)(66066001)(40100003)(83716003)(19580395003)(87936001)(2351001)(450100001)(221733001)(5008740100001)(19617315012)(57306001)(82746002)(50226001)(86362001)(97736004)(101416001)(50986999)(19580405001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_11FD058687A0473BBD554CE984CAF587gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2015 06:34:05.8218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 210.227.101.105 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Agenda X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 06:34:26 -0000 --_000_11FD058687A0473BBD554CE984CAF587gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The agenda is up for our meeting at IETF94 (with changes made). If you have= queries let us know! https://datatracker.ietf.org/meeting/94/agenda/slim/ Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org Tokyo, Japan This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_11FD058687A0473BBD554CE984CAF587gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <977D3E4FA78B37478BDA6F8B97F42A1E@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi all,

The agenda is up for our meeting at IETF94 (with changes made). If you have= queries let us know!

https://datatracker.ietf.org/meeting/94/agenda/slim/

Natasha


Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA= | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


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

--_000_11FD058687A0473BBD554CE984CAF587gsmacom_--