From nobody Fri Apr 1 05:47:32 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505BE12D128 for ; Fri, 1 Apr 2016 05:47:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ1AsHykG_fp for ; Fri, 1 Apr 2016 05:47:26 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0642.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A5912D0FA for ; Fri, 1 Apr 2016 05:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V5j0ubJNIfeOSfTkDsznmkEQyHk5IK4pgbnWUrG7xpo=; b=m3mnx7Zh3AxtVuWQf3oCjh3DiBO4XjJYqU3fUzC7lFIMYBVli5XJi7ODCM/qyLxv9UXTjCRPb4yzoffTZJ8Az6faL/+f3yJaYU2ajy+fpQpfU5kvxBlez0ECYg5nNiAGVwMLZWkRB5+Wupr9FiVcQns18EVSsch01nIk7r/WZ3M= Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1035.eurprd04.prod.outlook.com (10.162.26.144) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 1 Apr 2016 12:47: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.0447.025; Fri, 1 Apr 2016 12:47:05 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: [Slim] IETF95, was: Re: Change proposals for draft-ietf-slim-negotiating-human-language-00.txt Thread-Index: AQHRjBSYNW/3RRoiKU6hVrEWRw6q3Q== Date: Fri, 1 Apr 2016 12:47:05 +0000 Message-ID: <0357F304-0E38-45A7-8902-453B43D8270A@gsma.com> References: <20151102160934.3160.2433.idtracker@ietfa.amsl.com> <56E8FEF0.10503@omnitor.se> <56EF9277.7040306@omnitor.se> <56F05DF9.2080802@omnitor.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [87.112.202.8] x-ms-office365-filtering-correlation-id: ecbd9df2-8f34-4f0d-3519-08d35a2bbac4 x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:LSyX+YVeJncff7yJo9SZUN6sQRrh6v0tKgPiZdpNCfRWcR1HdAgXeqXXkh5l1sqjQnROmpCJP13UnIVQkGf0IyYUFrkwEQe2sCyMARU8X2UvO9/zt+9MBxeZ8kbNuGVRtGkXv4cwFsGX4y1Y7vIAkA==; 24:NWMBwb9gzGw96eych/CN8q9/O5hwXjpAM7vJ//H6fX3LMyosbYPhuoTneTyQq2nsAmdOXYl7GxUi1O2SlAOoCmXs5l3gSbtImLNG4P4OU7M= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(53754006)(377424004)(377454003)(66654002)(3280700002)(1730700002)(92566002)(3660700001)(5002640100001)(33656002)(2501003)(2906002)(5890100001)(110136002)(107886002)(189998001)(1096002)(86362001)(1220700001)(76176999)(50226001)(6116002)(102836003)(10400500002)(50986999)(106116001)(3846002)(16236675004)(122556002)(5008740100001)(19580405001)(19580395003)(66066001)(11100500001)(87936001)(450100001)(230783001)(57306001)(82746002)(2351001)(36756003)(5004730100002)(19617315012)(77096005)(83716003)(5640700001)(2900100001)(2950100001)(15975445007)(586003)(81166005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0357F3040E3845A78902453B43D8270Agsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2016 12:47:05.1948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1035 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: 87.112.202.8 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: HE1PR04MB1035.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] IETF95, was: Re: Change proposals for draft-ietf-slim-negotiating-human-language-00.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 12:47:30 -0000 --_000_0357F3040E3845A78902453B43D8270Agsmacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all! I have uploaded an agenda for our meeting next week. Please let me know if = you wish to make any changes. I will also double check the remote participa= tion is set up for those who will be attending remotely. https://datatracker.ietf.org/meeting/95/agenda/slim/ Many thanks! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org On Mar 31, 2016, at 5:39 PM, Natasha Rooney > wrote: Hi all, It=92s about time (or, perhaps late by two weeks!) that we decide on our ag= enda for next week=92s meeting. We have an hour between 16:20-17:20 on Thur= sday and we will have both remote and present attendees. In this meeting we will be discussing the below open issue and updates that= have been made / will be made to the existing documents. The meeting shoul= d be less than an hour. A guidelines agenda is: Welcome Update on SLIM new and existing docs draft-ietf-slim-multilangcontent-00 draft-ietf-slim-negotiating-human-language-01 draft-ietf-slim-use-cases-00 Open Issue(s) If you have something else to add please do let me know as soon as you can = so I can add this to the agenda. I will publish this tomorrow. Also, please let me know if you are attending in person or not if you haven= =92t already! Thanks all! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org On Mar 21, 2016, at 8:47 PM, Gunnar Hellstr=F6m > wrote: Hi Randall, Den 2016-03-21 kl. 17:53, skrev Randall Gellens: Hi Gunnar, I do not believe we are forcing an interpretation on RFC 4566, rather, the = drafts says, in an explanatory aside in parentheses, how the authors interp= ret it. This is quite far from a normative statement. It will be documented anyway, and just as you looked at the discussion arou= nd the STOX - example and got influenced by it, there is a risk that we spr= ead more uncertainty in the topic or lead others to make unlogical conclusi= ons. Let it be sufficient to say that 'lang' does not have the detailing we need= . I have re-read the text on language directionality within a media stream, a= nd I do not see that we have an interoperability problem. It's possible tha= t multiple streams with a language in the same direction are established, a= nd it's possible that not all of them are actually used (e.g., if higher pr= iority streams are established, perhaps the lower priority ones are not use= d). I don't see that as causing an interoperability problem. See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just published= by Natasha. Thanks! Only 2.3 is solved by the current specification. The other needs cross-medi= a preferences. They could need media and language grouping as well, but I prefer that we t= ry to solve that with a rule saying that languages in different media speci= fied on the same preference level shall be seen as a group that is required= together, while languages in different media specified with different pref= erence levels specify single languages provided for selection. Note also that the primary function of these attributes are not to guide wh= ich media streams shall be accepted and activated, it is usually good with = media streams even if they are not used for language. The function I see as the main purpose is to make sure that the caller gets= in contact with a person with the right language competence and if needed = a suitable relay service is invoked in the call in order to cover any gaps = in language coverage. Of course a media stream must not be excluded that is needed for the select= ed language combination. But the opposite should not happen - that a media= stream is ignored because it is not needed for language communication. I could add a statement that both 'lang' and 'humintlang-' attributes shoul= d not be used in the same stream, due to potential confusion. Yes, if we cannot agree on how to interpret 'lang', it would be a solution. But the problem is also between media. 'lang' in one medium and 'humintlang= ' in another is also undefined if it represents an offered selection, or a = required combination and if selection, what preference levels do they repre= sent? We must then also think about the conflict between 'lang' on session level = and 'humintlang' on media level. /Gunnar At 7:19 AM +0100 3/21/16, Gunnar Hellstr=F6m wrote: Randall, I think it is unfair to RFC 4566 and RFC 3264 that we force an interpretati= on of the use of the 'lang' attribute on them that we do not agree on. If we do not come to an agreement, we could instead just refrain from docum= enting an interpretation of how the 'lang' attribute works and conclude wi= th "Unfortunately, there are cases, where the users need to use different modalities in different directions, and when it is important to combine languages in different modalities. The 'lang' attribute does not have the details needed to cover these cases." We must also make sure that we do not make the same kind of unders-pecifica= tion as apparently has been done in RFC 4566. We need to describe what it means if we have language indications for the s= ame direction in two (or more) media. Shall it be understood as an indication that 1) I am prepared to use both in the session or that 2) I require both to be used or that 3) I am not prepared to use both but offer them for selection. If the normal interpretation is that it is for selection of one, how is the= preference for one or the other indicated? And if the normal interpretation is for a selection, how do we then indicat= e the case when we really strongly prefer to get both. ( e.g. voice plus ca= ptions ). We also need to describe how use of both 'lang' and 'humintlang-' attribute= s in the same sdp shall be interpreted. Regards Gunnar Den 2016-03-21 kl. 01:32, skrev Randall Gellens: Hi Gunnar, Thanks very much for your comments. Please see in-line: At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote: In addition to the changes proposed in draft-ietf-slim-negotiating-human-l= anguage-00 for the preference regardless of media recently submitted, I hav= e the following proposals for changes: 1. Change the first paragraph of section 5 from: ---------------------------------------------------------------------------= ----------------------- RFC 4566 specifies an attribute 'lan= g' which sounds similar to what is needed here, the difference being that it specifies that 'a=3Dlang' is declarative with the semantics of multiple 'lang' attributes being that all of them are used, while we want a means to negotiate which one is used in each stream. This difference means that the existing 'lang' attribute can't be used and we need to define a new attribute. ---------------------------------------------------------------------------= ---- to ---------------------------------------------------------------------------= ------------ RFC 4566 specifies an attribute 'lan= g' which sounds similar to what is needed here. It specifies that 'a=3Dlang' is declarative with the semantics of multiple 'lang' attributes being possible, indicating a number of possible languages in the session in an order of preference. Each party declares their capabilities and the language(s) used in the session can then be selected from the common se= t. We have however a need to specify direction of use of each language, and an order of preference between languages in different modalities. This difference means that the existing 'lang' attribute is not suffici= ent for our use and we need to complement it with definition of a new attri= bute. ---------------------------------------------------------------------------= ----------------------- I disagree. I've reread the text in the draft and in RFC 4566 multiple tim= es. However, I added clarifying wording to the draft. 2. change the last two paragraphs of section 5 from: ---------------------------------------------------------------------------= ----------------------------- A recent search of RFCs and Internet Drafts turned up only one use of the 'lang' attribute (in a now-expired draft), and that sole use was coincidentally in exactly the way we need (erroniously assuming that the attribute was used for negotiation). The sole use was in an example in a draft not directly related to language, where the initial invitation contains two 'a=3Dlang' entries for a media stream (for English and Italian) and the OK accepts one of them (Italian). The example serves as evidence of the need for an SDP attribute with the semantics as described in this document; unfortunately, the existing 'lang' attribute is not it. ---------------------------------------------------------------------- to ---------------------------------------------------------------------------= -- A recent search of RFCs and Internet Drafts turned up only one use of the 'lang' attribute (in a now-expired draft), and that sole use was coincidentally in exactly the way we need. The sole use was in an example in a draft not directly related to language, where the initial invitation contains two 'a=3Dlang' entries for a media stream (for English and Italian) and the OK accepts one of them (Italian). This use was questioned in a discussion of that draft because of this sentence in RFC 4566: "Multiple lang attributes can be provided either at session or media level if the session description or media use multiple languages." An interpretation was that all declared languages must be used in the session, while the example showed use of a selection of the originally indicated languages. The uncertainty caused withdrawal of the example because it was not essential for the draft. However, studying the wording in RFC 4566 further, it is evident that a negotiation of languages was intended for the real-time case. When sdp is used to declare contents of a recorded session, then it makes sense to list the provided languages, while for a real-time session, it is obvious that the capabilities of the parties and the development of the session influence the selection of language for the session. The continuation in RFC 4566 "the order of the attributes indicates the order of importance of the various languages" makes it very clear that the list shall be seen as a list for selection and negotiation. The "order of importance" has no meaning if all languages must be provid= ed. The conclusion is that the 'lang' attribute can be used for negotiation of one or more common languages to select from for use in a real-time se= ssion. A clarification is prepared for a possible future revision of RFC 4566. Thus, the 'lang' attribute satisfies our needs in many cases. Unfortunately, there are cases, where the users need to use different modalities in different directions, and when it is important to combine languages in different modalities. The 'lang' attribute does not have the details needed to cover these cases." ---------------------------------------------------------------------------= ---------------------- While I disagree with your interpretation, I don't think it's needed to go = into this level of detail at this point in the draft, so I left it unchange= d. 3. Change section 6 from: ------------------------------------------------------- 6 Proposed Solution An SDP attribute seems the natural choice to negotiate human (natural) language of an interactive media stream. The attribute value should be a language tag per RFC 5646 [RFC5646] " ------------------------------------------------------------------ to ----------------------------------------------------------------------- 6 Proposed Solution An SDP attribute seems the natural choice to negotiate human (natural) language of an interactive media stream. The attribute value should be a language tag per RFC 5646 [RFC5646] The new attribute can appear together with the existing 'lang' attribute to compose the preferred language/modality combinations offered or negotiated. ---------------------------------------------------------------------- I don't think we have consensus on doing this, so I left it unchanged. -- ----------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim 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. _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim 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_0357F3040E3845A78902453B43D8270Agsmacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi all!

I have uploaded an agenda for our meeting next week. Please= let me know if you wish to make any changes. I will also double check the = remote participation is set up for those who will be attending remotely.

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

Many thanks!

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;


On Mar 31, 2016, at 5:39 PM, Natasha Rooney <nrooney@gsma.com> wrote:

Hi all,

It=92s about time (or, perhaps late by two weeks!) that we decide on our ag= enda for next week=92s meeting. We have an hour between 16:20-17:20 on Thur= sday and we will have both remote and present attendees.

In this meeting we will be discussing the below open issue and updates that= have been made / will be made to the existing documents. The meeting shoul= d be less than an hour. A guidelines agenda is:

Welcome
Update on SLIM new and existing docs
draft-ietf-= slim-multilangcontent-00 
draft-ietf-= slim-negotiating-human-language-01 
draft-ietf-= slim-use-cases-00 
Open Issue(s)

If you have something else to add please do let me know as soon as you can = so I can add this to the agenda. I will publish this tomorrow.

Also, please let me know if you are attending in person or not if you haven= =92t already!

Thanks all!

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;


On Mar 21, 2016, at 8:47 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor= .se> wrote:

Hi Randall,
Den 2016-03-21 kl. 17:53, skrev Randall Gellens:
Hi Gunnar,

I do not believe we are forcing an interpretation on RFC 4566, rather, the = drafts says, in an explanatory aside in parentheses, how the authors interp= ret it.  This is quite far from a normative statement.
It will be documented anyway, and just as you looked at the discussion arou= nd the STOX - example and got influenced by it, there is a risk that we spr= ead more uncertainty in the topic or lead others to make unlogical conclusi= ons.
Let it be sufficient to say that 'lang' does not have the detailing we need= .


I have re-read the text on language directionality within a media stream, a= nd I do not see that we have an interoperability problem. It's possible tha= t multiple streams with a language in the same direction are established, a= nd it's possible that not all of them are actually used (e.g., if higher priority streams are established, = perhaps the lower priority ones are not used).  I don't see that as ca= using an interoperability problem.
See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just published= by Natasha. Thanks!
Only 2.3 is solved by the current specification. The other needs cross-medi= a preferences.
They could need media and language grouping as well, but I prefer that we t= ry to solve that with a rule saying that languages in different media speci= fied on the same preference level shall be seen as a group that is required= together, while languages in different media specified with different preference levels specify single languages = provided for selection.


Note also that the primary function of these attributes are not to guide wh= ich media streams shall be accepted and activated, it is usually good with = media streams even if they are not used for language.
The function I see as the main purpose is to make sure that the caller gets= in contact with a person with the right language competence and if needed = a suitable relay service is invoked in the call in order to cover any gaps = in language coverage.
Of course a media stream must not be excluded that is needed for the select= ed language combination.  But the opposite should not happen - that a = media stream is ignored because it is not needed for language communication= .



I could add a statement that both 'lang' and 'humintlang-' attributes shoul= d not be used in the same stream, due to potential confusion.
Yes, if we cannot agree on how to interpret 'lang', it would be a solution.=
But the problem is also between media. 'lang' in one medium and 'humintlang= ' in another is also undefined if it represents an offered selection, or a = required combination and if selection, what preference levels do they repre= sent?
We must then also think about the conflict between 'lang' on session level = and 'humintlang' on media level.


/Gunnar

At 7:19 AM +0100 3/21/16, Gunnar Hellstr=F6m wrote:

Randall,

I think it is unfair to RFC 4566 and RFC 3264 that we force an interpretati= on of the use of the 'lang' attribute on them that we do not agree on.

If we do not come to an agreement, we could instead just refrain from docum= enting an interpretation of how the 'lang' attribute works and  conclu= de with

"Unfortunately, there are cases, where the users need to use different=
   modalities in different directions, and when it is import= ant to combine
   languages in different modalities. The 'lang' attribute d= oes not have
   the details needed to cover these cases."

We must also make sure that we do not make the same kind of unders-pecifica= tion as apparently has been done in RFC 4566.
We need to describe what it means if we have language indications for the s= ame direction in two (or more) media.
Shall it be understood as an indication that
    1) I am prepared to use both in the session or that=
    2) I require both to be used or that
    3) I am not prepared to use both but offer them for= selection.
If the normal interpretation is that it is for selection of one, how is the= preference for one or the other indicated?
And if the normal interpretation is for a selection, how do we then indicat= e the case when we really strongly prefer to get both. ( e.g. voice plus ca= ptions ).

We also need to describe how use of both 'lang' and 'humintlang-' attribute= s in the same sdp shall be interpreted.

Regards

Gunnar


Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
Hi Gunnar,

Thanks very much for your comments.  Please see in-line:

At 7:36 AM +0100 3/16/16, Gunnar Hellstr=F6m wrote:

 In addition to the changes propo= sed in draft-ietf-slim-negotiating-human-language-00 for the preference reg= ardless of media recently submitted, I have the following proposals for cha= nges:

 1. Change the first paragraph of section 5 from:


---------------------------------------------------------------------------= -----------------------
  <= https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an attribute = 'lang' which sounds similar to what
    is needed here, the difference being that it specif= ies that 'a=3Dlang'
    is declarative with the semantics of multiple 'lang= ' attributes being
    that all of them are used, while we want a means to= negotiate which
    one is used in each stream.  This difference m= eans that the existing
    'lang' attribute can't be used and we need to defin= e a new attribute.

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

 to


---------------------------------------------------------------------------= ------------
  <= https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an attribute = 'lang' which sounds similar to what
    is needed here. It specifies that 'a=3Dlang'
    is declarative with the semantics of multiple 'lang= ' attributes being
    possible, indicating a number of possible languages= in the session in
    an order of preference. Each party declares their c= apabilities and the
    language(s) used in the session can then be selecte= d from the common set.
    We have however a need to specify direction of use = of each language,
    and an order of preference between languages in dif= ferent modalities.
    This difference means that the existing 'lang' attr= ibute is not sufficient
    for our use and we need to complement it with defin= ition of a new attribute.


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

I disagree.  I've reread the text in the draft and in RFC 4566 multipl= e times.  However, I added clarifying wording to the draft.


 2. change the last two paragraphs of section 5 from:


---------------------------------------------------------------------------= -----------------------------
  A recent search of RFCs and Internet Drafts turned up only one = use of
    the 'lang' attribute (in a now-expired draft), and = that sole use was
    coincidentally in exactly the way we need (erroniou= sly assuming that
    the attribute was used for negotiation).  The = sole use was in an
    example in a draft not directly related to language= , where the
    initial invitation contains two 'a=3Dlang' entries = for a media stream
    (for English and Italian) and the OK accepts one of= them (Italian).

    The example serves as evidence of the need for an S= DP attribute with
    the semantics as described in this document; unfort= unately, the
    existing 'lang' attribute is not it.
----------------------------------------------------------------------
 to

---------------------------------------------------------------------------= --
  A recent search of RFCs and Internet Drafts turned up only one = use of
    the 'lang' attribute (in a now-expired draft), and = that sole use was
    coincidentally in exactly the way we need.  Th= e sole use was in an
    example in a draft not directly related to language= , where the
    initial invitation contains two 'a=3Dlang' entries = for a media stream
    (for English and Italian) and the OK accepts one of= them (Italian).

    This use was questioned in a discussion of that dra= ft because of this
    sentence in RFC 4566: "Multiple lang attribute= s can be
       provided either at session or med= ia level if the session
       description or media use multiple= languages."
    An interpretation was that all declared languages m= ust be used in
    the session, while the example showed use of a sele= ction of the
    originally indicated languages. The uncertainty cau= sed withdrawal
    of the example because it was not essential for the= draft.

   However, studying the wording in RFC 4566 further, it is = evident
   that a negotiation of languages was intended for the real= -time case.
   When sdp is used to declare contents of a recorded sessio= n, then it
   makes sense to list the provided languages, while for a r= eal-time
   session, it is obvious that the capabilities of the parti= es and the
   development of the session influence the selection of lan= guage for
   the session.
   The continuation in RFC 4566 "the order of the attri= butes indicates
   the order of importance of the various languages" ma= kes it very clear
   that the list shall be seen as a list for selection and n= egotiation.
   The "order of importance" has no meaning if all= languages must be provided.

   The conclusion is that the 'lang' attribute can be used f= or negotiation
   of one or more common languages to select from for use in= a real-time session.
   A clarification is prepared for a possible future revisio= n of RFC 4566.

   Thus, the 'lang' attribute satisfies our needs in many ca= ses.

   Unfortunately, there are cases, where the users need to u= se different
   modalities in different directions, and when it is import= ant to combine
   languages in different modalities. The 'lang' attribute d= oes not have
   the details needed to cover these cases."


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

While I disagree with your interpretation, I don't think it's needed to go = into this level of detail at this point in the draft, so I left it unchange= d.


 3. Change section 6 from:
 -------------------------------------------------------
 6 Proposed Solution
    An SDP attribute seems the natural choice to negoti= ate human
    (natural) language of an interactive media stream. =  The attribute
    value should be a language tag per <https://tools.ietf.org/html/= rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646] "
------------------------------------------------------------------
 to
-----------------------------------------------------------------------  6 Proposed Solution
    An SDP attribute seems the natural choice to negoti= ate human
    (natural) language of an interactive media stream. =  The attribute
    value should be a language tag per <https://tools.ietf.org/html/= rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646]
    The new attribute can appear together with the exis= ting 'lang'
    attribute to compose the preferred language/modalit= y combinations
    offered or negotiated.
----------------------------------------------------------------------

I don't think we have consensus on doing this, so I left it unchanged.


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

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



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

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

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.

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

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_0357F3040E3845A78902453B43D8270Agsmacom_-- From nobody Tue Apr 5 14:11:49 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3408112D5A0 for ; Tue, 5 Apr 2016 14:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEDkaS2zwdQl for ; Tue, 5 Apr 2016 14:11:44 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0067.outbound.protection.outlook.com [104.47.1.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BD312D182 for ; Tue, 5 Apr 2016 14:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9owGBxsa6YDn/TcFffFzLjiK3zPLSFAueP6gjt5JAvA=; b=YWLZ1hrVJiI+LWIFt3Wz2phwBDEoS/yAI0buKl9LmpNc8WWFoz69SOVBlZnHgXo1NkoFDBOz5XT0wu6zNAmu7XJWQGZy2rlBOxdHwX95uVMLYlrKoQp/2wVst1dyshj3Cnuy7lKxQDJ9pqdqpYhKgTchFPZeBwclaXYEbQqxbRE= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2063.eurprd04.prod.outlook.com (10.166.141.137) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 21:11:41 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0447.028; Tue, 5 Apr 2016 21:11:41 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: Remote presenters for Thursday Thread-Index: AQHRj3/A4jR1/6m17UO1eQ1TASOlzg== Date: Tue, 5 Apr 2016 21:11:41 +0000 Message-ID: <5EFB692F-7054-4442-B6C8-1A456C34957E@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.3112) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.160.207] x-ms-office365-filtering-correlation-id: 14c5cddb-7eed-4c7f-5e07-08d35d96e2a7 x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2063; 5:LqjV2ph4Twbaiq/LC6E/06TR765MiNXQoQMv45PJwZYxGRbEKufjfGmFL+8Qfe4E9ZrrH2r9xcJzuVHoRvKx5d9/TcqjzzjDJX9WTvhZ16Vg6xhhOhY64vAF3EJ0eNG9p3H7ueigijJs5typN9R+dQ==; 24:jJwzVdMbO+tT+KUAfQLWzcEJZL6SnOPpcbHCtPRchLoFfGIIIHS1RF5gwRkw9q6OUML93l/huDvBVrM4BWu0pPAvHJ112GjVvQZcOkjltz8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2063; 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)(10201501046); SRVR:VI1PR0401MB2063; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2063; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(5890100001)(586003)(3846002)(5640700001)(77096005)(6116002)(3480700003)(3280700002)(2906002)(1096002)(3660700001)(5002640100001)(1220700001)(2501003)(2900100001)(81166005)(106116001)(33656002)(57306001)(1730700002)(16236675004)(102836003)(15975445007)(66066001)(5004730100002)(19617315012)(19580395003)(92566002)(19580405001)(87936001)(189998001)(36756003)(5008740100001)(122556002)(2351001)(110136002)(107886002)(450100001)(83716003)(86362001)(82746002)(50986999)(11100500001)(10400500002)(229853001)(50226001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2063; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5EFB692F70544442B6C81A456C34957Egsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2016 21:11:41.7062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2063 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.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: 31.133.160.207 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: VI1PR0401MB2063.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] Remote presenters for Thursday X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:11:47 -0000 --_000_5EFB692F70544442B6C81A456C34957Egsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, If any of you are presenting / attending remotely on Thursday it would be g= reat if you could get a little accustomed to Meetecho before the meeting. I= f you are presenting you should have received an email with some details fr= om Meetecho (if not please let me know). Please see a link below for more i= nfo on remote attending with Meetecho: https://ietf95.conf.meetecho.com/ Thanks everyone! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_5EFB692F70544442B6C81A456C34957Egsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <428D5467CF2BE744AAC0D42D9389AA8C@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Guys,

If any of you are presenting / attending remotely on Thursd= ay it would be great if you could get a little accustomed to Meetecho befor= e the meeting. If you are presenting you should have received an email with= some details from Meetecho (if not please let me know). Please see a link below for more info on remote atten= ding with Meetecho:
ht= tps://ietf95.conf.meetecho.com/

Thanks everyone!

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;


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_5EFB692F70544442B6C81A456C34957Egsmacom_-- From nobody Thu Apr 7 01:50:54 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7321F12D5D2 for ; Thu, 7 Apr 2016 01:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PBx7Al0Iwc6 for ; Thu, 7 Apr 2016 01:50:49 -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 A027312D136 for ; Thu, 7 Apr 2016 01:50:48 -0700 (PDT) X-Halon-ID: cd204bf3-fc9d-11e5-8ff9-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.39] (unknown [87.96.161.49]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 7 Apr 2016 10:50:38 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <57061F60.4020208@omnitor.se> Date: Thu, 7 Apr 2016 10:50:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080200010605000605040608" Archived-At: Subject: [Slim] Change proposals for the real-time SLIM draft X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 08:50:53 -0000 This is a multi-part message in MIME format. --------------080200010605000605040608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Here is a modified re-issue of change proposals I have made for the real-time humintlang draft, https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ The reasoning for proposing them are still valid and need to be solved, so I suggest that continued work to satisfy the requirements are based on these change proposals. *A: The current "lang" attribute is intended for selection by offer-answer and not as a mandatory list.* The discussion about the current 'lang' attribute in sections 5 and 6 is misleading and should be changed. The attribute is useful. 1. Change the first paragraph of section 5 from: -------------------------------------------------------------------------------------------------- RFC 4566 specifies an attribute 'lang' which sounds similar to what is needed here, the difference being that it specifies that 'a=lang' is declarative with the semantics of multiple 'lang' attributes being that all of them are used, while we want a means to negotiate which one is used in each stream. This difference means that the existing 'lang' attribute can't be used and we need to define a new attribute. ------------------------------------------------------------------------------- to --------------------------------------------------------------------------------------- RFC 4566 specifies an attribute 'lang' which sounds similar to what is needed here. It specifies that 'a=lang' is declarative with the semantics of multiple 'lang' attributes being possible, indicating a number of possible languages in the session in an order of preference. Each party declares their capabilities and the language(s) used in the session can then be selected from the common set. We have however a need to specify direction of use of each language, and an order of preference between languages in different modalities. This difference means that the existing 'lang' attribute is not sufficient for our use and we need to complement it with definition of a new attribute. -------------------------------------------------------------------------------------------------- 2. change the last two paragraphs of section 5 from: -------------------------------------------------------------------------------------------------------- A recent search of RFCs and Internet Drafts turned up only one use of the 'lang' attribute (in a now-expired draft), and that sole use was coincidentally in exactly the way we need (erroneously assuming that the attribute was used for negotiation). The sole use was in an example in a draft not directly related to language, where the initial invitation contains two 'a=lang' entries for a media stream (for English and Italian) and the OK accepts one of them (Italian). The example serves as evidence of the need for an SDP attribute with the semantics as described in this document; unfortunately, the existing 'lang' attribute is not it. ---------------------------------------------------------------------- to ----------------------------------------------------------------------------- A recent search of RFCs and Internet Drafts turned up only one use of the 'lang' attribute (in a now-expired draft), and that sole use was coincidentally in exactly the way we need. The sole use was in an example in a draft not directly related to language, where the initial invitation contains two 'a=lang' entries for a media stream (for English and Italian) and the OK accepts one of them (Italian). This use was questioned in a discussion of that draft because of this sentence in RFC 4566: "Multiple lang attributes can be provided either at session or media level if the session description or media use multiple languages." An interpretation was that all declared languages must be used in the session, while the example showed use of a selection of the originally indicated languages. The uncertainty caused withdrawal of the example because it was not essential for the draft. However, studying the wording in RFC 4566 further, it is evident that a negotiation of languages was intended for the real-time case. When sdp is used to declare contents of a recorded session, then it makes sense to list the provided languages, while for a real-time session, it is obvious that the capabilities of the parties and the development of the session influence the selection of language for the session. The continuation in RFC 4566 "the order of the attributes indicates the order of importance of the various languages" makes it very clear that the list shall be seen as a list for selection and negotiation. The "order of importance" has no meaning if all languages must be provided. The conclusion is that the 'lang' attribute can be used for negotiation of one or more common languages to select from for use in a real-time session. A clarification is prepared for a possible future revision of RFC 4566. Thus, the 'lang' attribute satisfies our needs in many cases. Unfortunately, there are cases, where the users need to use different modalities in different directions, and when it is important to combine languages in different modalities. The 'lang' attribute does not have the details needed to cover these cases." ------------------------------------------------------------------------------------------------- 3. Change section 6 from: ------------------------------------------------------- 6 Proposed Solution An SDP attribute seems the natural choice to negotiate human (natural) language of an interactive media stream. The attribute value should be a language tag per RFC 5646 [RFC5646] " ------------------------------------------------------------------ to ----------------------------------------------------------------------- 6 Proposed Solution An SDP attribute seems the natural choice to negotiate human (natural) language of an interactive media stream. The attribute value should be a language tag per RFC 5646 [RFC5646] The new attribute can appear together with the existing 'lang' attribute to compose the preferred language/modality combinations offered or negotiated. ---------------------------------------------------------------------- *B: Need for notation of combinations of languages and priority assignment valid across multi m-lines* Some use cases require clearly priority - ordered alternatives in different modalities. Other use cases require a combination of one language/modality in one direction and another language/modality in the other direction. Coding to express such needs and offerings must be included. And we must not cause uncertainty about if the indications are seen as a list where all must be provided or a list for selection in an offer/answer exchange. -------------------------------------current text in 6.2------------------------------------------------- a=humintlang-send: a=humintlang-recv: Each can appear multiple times in an offer for a media stream. In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send using the media, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive using the media. -------------------------------------proposed changed text in 6.2---------------------------------- a=humintlang-send:[ ";" "q" "=" qvalue ] a=humintlang-recv:[ ";" "q" "=" qvalue ] Each can appear multiple times in an offer or answer for a media stream. In an offer or answer the 'humintlang-send' values constitute a list of the languages the party is capable to select from for sending using the media, and the 'humintlang-recv' values constitute a list of the languages in which the party is capable of receiving contents using the media. The q-values represent a preference level for using the indicated language and modality relative to all other languages and modalities indicated for the same direction in the whole SDP. The quality value defaults to "q=1" and has the same syntax and usage rules as for 'Accept-Language' in RFC 2616 [RFC2616]. If more than one language is specified in the SDP with the same q-value, it indicates a required grouping. If one of these languages is selected to be used, then all with that q-value SHALL be used. Languages specified with the "lang" attribute SHALL be regarded to have the q-value 0.5. An answer SHALL only contain language specifications selected from the offer. It is RECOMMENDED that the answer selects one complete set of language indications for conducting a conversation and thereby giving the offeror a clear indication of which language(s) will be used. If an answer does not include any language indication, then the session participants are left to use other means than the language indications to select the languages used (if any) in the session. ---------------------------------End of change proposal.--------------------------------------------- -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------080200010605000605040608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Here is a modified re-issue of change proposals I have made for the real-time humintlang draft,
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

The reasoning for proposing them are still valid and need to be solved, so I suggest that continued work to satisfy the requirements are based on these change proposals.

A: The current "lang" attribute is intended for selection by offer-answer and not as a mandatory list.
The discussion about the current 'lang' attribute in sections 5 and 6 is misleading and should be changed. The attribute is useful.

1. Change the first paragraph of section 5 from:
--------------------------------------------------------------------------------------------------

 RFC 4566 specifies an attribute 'lang' which sounds similar to what
   is needed here, the difference being that it specifies that 'a=lang'
   is declarative with the semantics of multiple 'lang' attributes being
   that all of them are used, while we want a means to negotiate which
   one is used in each stream.  This difference means that the existing
   'lang' attribute can't be used and we need to define a new attribute. 
-------------------------------------------------------------------------------


to
---------------------------------------------------------------------------------------

 RFC 4566 specifies an attribute 'lang' which sounds similar to what
   is needed here. It specifies that 'a=lang'
   is declarative with the semantics of multiple 'lang' attributes being
   possible, indicating a number of possible languages in the session in
   an order of preference. Each party declares their capabilities and the
   language(s) used in the session can then be selected from the common set.
   We have however a need to specify direction of use of each language,
   and an order of preference between languages in different modalities.
   This difference means that the existing 'lang' attribute is not sufficient
   for our use and we need to complement it with definition of a new attribute.
--------------------------------------------------------------------------------------------------


2. change the last two paragraphs of section 5 from:
--------------------------------------------------------------------------------------------------------

 A recent search of RFCs and Internet Drafts turned up only one use of
   the 'lang' attribute (in a now-expired draft), and that sole use was
   coincidentally in exactly the way we need (erroneously assuming that
   the attribute was used for negotiation).  The sole use was in an
   example in a draft not directly related to language, where the
   initial invitation contains two 'a=lang' entries for a media stream
   (for English and Italian) and the OK accepts one of them (Italian).

   The example serves as evidence of the need for an SDP attribute with
   the semantics as described in this document; unfortunately, the
   existing 'lang' attribute is not it.
----------------------------------------------------------------------
to
-----------------------------------------------------------------------------
 A recent search of RFCs and Internet Drafts turned up only one use of
   the 'lang' attribute (in a now-expired draft), and that sole use was
   coincidentally in exactly the way we need.  The sole use was in an
   example in a draft not directly related to language, where the
   initial invitation contains two 'a=lang' entries for a media stream
   (for English and Italian) and the OK accepts one of them (Italian).

   This use was questioned in a discussion of that draft because of this
   sentence in RFC 4566: "Multiple lang attributes can be
      provided either at session or media level if the session
      description or media use multiple languages."
   An interpretation was that all declared languages must be used in
   the session, while the example showed use of a selection of the
   originally indicated languages. The uncertainty caused withdrawal
   of the example because it was not essential for the draft.

  However, studying the wording in RFC 4566 further, it is evident
  that a negotiation of languages was intended for the real-time case.
  When sdp is used to declare contents of a recorded session, then it
  makes sense to list the provided languages, while for a real-time
  session, it is obvious that the capabilities of the parties and the
  development of the session influence the selection of language for
  the session.
  The continuation in RFC 4566 "the order of the attributes indicates
  the order of importance of the various languages" makes it very clear
  that the list shall be seen as a list for selection and negotiation.
  The "order of importance" has no meaning if all languages must be provided.

  The conclusion is that the 'lang' attribute can be used for negotiation
  of one or more common languages to select from for use in a real-time session.
  A clarification is prepared for a possible future revision of RFC 4566.

  Thus, the 'lang' attribute satisfies our needs in many cases.

  Unfortunately, there are cases, where the users need to use different
  modalities in different directions, and when it is important to combine
  languages in different modalities. The 'lang' attribute does not have
  the details needed to cover these cases."
-------------------------------------------------------------------------------------------------

3. Change section 6 from:
-------------------------------------------------------
6 Proposed Solution

   An SDP attribute seems the natural choice to negotiate human
   (natural) language of an interactive media stream.  The attribute
   value should be a language tag per RFC 5646 [RFC5646] "
------------------------------------------------------------------
to
-----------------------------------------------------------------------
6 Proposed Solution
   An SDP attribute seems the natural choice to negotiate human
   (natural) language of an interactive media stream.  The attribute
   value should be a language tag per RFC 5646 [RFC5646]
   The new attribute can appear together with the existing 'lang'
   attribute to compose the preferred language/modality combinations
   offered or negotiated.
----------------------------------------------------------------------

B: Need for notation of combinations of languages and priority assignment valid across multi m-lines
Some use cases require clearly priority - ordered alternatives in different modalities.
Other use cases require a combination of one language/modality in one direction and another language/modality in the other direction.
Coding to express such needs and offerings must be included.

And we must not cause uncertainty about if the indications are seen as a list where all must be provided or a list for selection in an offer/answer exchange.

-------------------------------------current text in 6.2-------------------------------------------------

      a=humintlang-send:<language tag>
      a=humintlang-recv:<language tag>

   Each can appear multiple times in an offer for a media stream.

   In an offer, the 'humintlang-send' values constitute a list in
   preference order (first is most preferred) of the languages the
   offerer wishes to send using the media, and the 'humintlang-recv'
   values constitute a list in preference order of the languages the
   offerer wishes to receive using the media.



-------------------------------------proposed changed text in 6.2----------------------------------

      a=humintlang-send:<language tag>[ ";" "q" "=" qvalue ]

      a=humintlang-recv:<language tag>[ ";" "q" "=" qvalue ]


   Each can appear multiple times in an offer or answer for a media stream.

   In an offer or answer the 'humintlang-send' values constitute a list of the languages the
   party is capable to select from for sending using the media, and the 'humintlang-recv'
   values constitute a list of the languages in which the party is capable of receiving contents
   using the media.  The q-values represent a preference level
   for using the indicated language and modality relative to all other languages and
   modalities indicated for the same direction in the whole SDP.
   The quality value defaults to "q=1" and has the same syntax and usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].

   If more than one language is specified in the SDP with the same q-value, it indicates a required grouping.
   If one of these languages is selected to be used, then all with that q-value SHALL be used.

Languages specified with the "lang" attribute SHALL be regarded to have the q-value 0.5.

  An answer SHALL only contain language specifications selected from the offer. It is RECOMMENDED that the answer selects one complete set of language indications for conducting a conversation and thereby giving the offeror a clear indication of which language(s) will be used.

If an answer does not include any language indication, then the session participants are left to use other means than the language indications to select the languages used (if any) in the session.
 
---------------------------------End of change proposal.---------------------------------------------

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------080200010605000605040608-- From nobody Thu Apr 7 05:13:04 2016 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 5AAF612D847; Thu, 7 Apr 2016 05:13:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 05:13:00 -0700 Archived-At: Cc: slim@ietf.org Subject: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:13:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media of the IETF. Title : SLIM Use Cases Author : Natasha Rooney Filename : draft-ietf-slim-use-cases-01.txt Pages : 7 Date : 2016-04-07 Abstract: Use cases for selection of language for internet media. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-slim-use-cases-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-use-cases-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 7 05:22:09 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD512D867 for ; Thu, 7 Apr 2016 05:22:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNjlVyoqyxej for ; Thu, 7 Apr 2016 05:22:04 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::628]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424A212D832 for ; Thu, 7 Apr 2016 05:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ewJyA93ETVkWWhwAf1gFZ6hrTLczI/69ITpj6qJ4b1k=; b=VsKj2L2coobSScdtICKSIxGlaKsGffofhQWKY8hhqtLuQUMaLrb0rRgAeF50uSP5GXs8pyZ0ss2wUmaXWLk5P0HWlcVShYRTpmJ4izIzTGddyV7MQghw5sh5NP4U0rzXUQ9pa8+KufuG1j4k+d/TEO/a8oyzCOgU3Dlb+W/B1ds= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2061.eurprd04.prod.outlook.com (10.166.141.135) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 12:21:45 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0453.027; Thu, 7 Apr 2016 12:21:45 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt Thread-Index: AQHRkMbZCzl1xCx8ck+ZX/m2Ru678J9+bouA Date: Thu, 7 Apr 2016 12:21:45 +0000 Message-ID: <2DD5E543-6AF7-445F-8F3E-0E056784B384@gsma.com> References: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> In-Reply-To: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:160:157f:ffa5:aa83:5021] x-ms-office365-filtering-correlation-id: 4a85b618-d422-469f-096d-08d35edf2f3f x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2061; 5:5E7xAlxCn+D1rjrIwqs9oY8bx4ogvm031lwq9+R6Ciks9E/zRH0vdAZv115eagl+lQ7AAioJpc40qMCoYYjckMK4sJ6nDOKTaGMlYTzQmNGaKgtMnt8blj+OrhD8+0xLo7Y8bZ6h744+RMgvO1UF4w==; 24:447Kr1tKeTov/FDam8SoS3INcKCw1FUtz3kQnTgaMXR6fD56+D60VJOZWiyOjEv9lUbh5c1dI5YNu6Za+Jz4lRMQobITY7onIrymmDp680c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2061; 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)(10201501046)(3002001); SRVR:VI1PR0401MB2061; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2061; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(377424004)(106116001)(3660700001)(11100500001)(5004730100002)(2351001)(36756003)(102836003)(2501003)(1220700001)(2900100001)(2950100001)(10400500002)(1730700002)(2906002)(15975445007)(50986999)(86362001)(76176999)(77096005)(92566002)(19617315012)(107886002)(87936001)(110136002)(3280700002)(122556002)(33656002)(5890100001)(82746002)(57306001)(50226001)(16236675004)(5640700001)(230783001)(189998001)(19580395003)(81166005)(5002640100001)(1096002)(450100001)(19580405001)(83716003)(5008740100001)(586003)(6116002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2061; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2DD5E5436AF7445F8F3E0E056784B384gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 12:21:45.1187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2061 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:67c:370:160:157f:ffa5:aa83:5021 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: VI1PR0401MB2061.eurprd04.prod.outlook.com Archived-At: Subject: Re: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:22:07 -0000 --_000_2DD5E5436AF7445F8F3E0E056784B384gsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ahead of our meeting today I published a mildly updated and cleaner version= of the use cases document. Speak to you all later! Natasha Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | nroone= y@gsma.com | +44 (0) 7730 219 765 | @thisNatasha |= Skype: nrooney@gsm.org On Apr 7, 2016, at 9:13 AM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Selection of Language for Internet Media o= f the IETF. Title : SLIM Use Cases Author : Natasha Rooney Filename : draft-ietf-slim-use-cases-01.txt Pages : 7 Date : 2016-04-07 Abstract: Use cases for selection of language for internet media. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-slim-use-cases-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-slim-use-cases-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ SLIM mailing list SLIM@ietf.org https://www.ietf.org/mailman/listinfo/slim 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_2DD5E5436AF7445F8F3E0E056784B384gsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Ahead of our meeting today I published a mildly updated and cleaner version= of the use cases document.

Speak to you all later!

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;


On Apr 7, 2016, at 9:13 AM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Selection of Language for Internet Media o= f the IETF.

       Title     &nb= sp;     : SLIM Use Cases
       Author     &n= bsp;    : Natasha Rooney
Filename &n= bsp;      : draft-ietf-slim-use-cases-01.txt<= br class=3D""> Pages  = ;         : 7
Date  =           : 2016-04-07
Abstract:
  Use cases for selection of language for internet media.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-use-cases-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-slim-use-cases-01


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

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

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

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_2DD5E5436AF7445F8F3E0E056784B384gsmacom_-- From nobody Thu Apr 7 11:29:29 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2B12D164 for ; Thu, 7 Apr 2016 11:29:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw_BQKi7F4d4 for ; Thu, 7 Apr 2016 11:29:26 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 722E912D0F0 for ; Thu, 7 Apr 2016 11:29:26 -0700 (PDT) Received: from dhcp-93ce.meeting.ietf.org (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 7 Apr 2016 11:29:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> References: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Thu, 7 Apr 2016 11:29:20 -0700 To: Natasha Rooney From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:29:28 -0000 ---------- Use case 2.4, change the text: Old: An answering service will have no guidance to which is the preferred modality and may select to use the modality that is the callers last resort even if the preferred alternative is available. To: An answering service will have no guidance to which is the preferred modality and thus all supported modalities might be set up. The caller and answerer then use the preferred modalities and ignore the non-preferred ones. The text: Old: In order to not miss any calls, the indication of text as last resort would be desirable. o Solution: need coding of an absolute preference: hi, med, lo together with the tag. Should be deleted. An absolute preference is not needed. The worst case outcome is that unused media streams are established. ---------- In use case 2.5, replace the text: Old: (There is no current solution that says that the text path is important. The answering part may see it as an alternative.) o Solution: Need for preference indication per modality New: Both modalities are established, and used as preferred by the humans. o Solution: Possible ---------- Use case 2.5.1, replace the text: Old: There currently are methods to indicate that the call shall fail if a language is not met, but that may be too drastic for some users including the one in the above scenario (Section 2.5). It may be important to be able to connect and just say something, or use residual hearing to get something back when the voice is familiar. o Possible solution: coding of an absolute preference together with the tag could solve this case if used together with the directional indications. For example: "preference: hi, med, lo" Another solution would be to indicate required grouping of media, however this raises the complexity level. New: There currently are methods to indicate if the call should fail or proceed when no languages are in common. In situations such as the above scenario (Section 2.5), it may be important to be able to connect and just say something, or use residual hearing to get something back when the voice is familiar. With emergency calls, it is useful for the PSAP call taker to be able to hear background and anciliary sounds even if unable to speak to the caller. o Solution: Possible ---------- In use case 2.6, change: OLD: direction and find the only possible combination. o Solution: Need for preference indication per modality New: direction and find possible combinations. o Solution: Possible ---------- Use cases 2.7, 2.8: Delete "and absolute level of preference indication" from Solution. ---------- Section 3: Typo in line #2: "language of" should be "language or" Typo in line #5: "allow give" should choose one. Delete "as well as an indication of absolute preference" from second paragraph. Delete "seem to be needed" from end of last sentence of second paragraph. ---------- Section 4: I think this is more properly a privacy consideration, so consider adding a privacy considerations section with this text, and changing the security considerations to say something such as "no additional security risks have been identified by the ability to indicate language." -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Your analyst has you mixed up with another patient. Don't believe a thing he tells you. From nobody Thu Apr 7 13:04:21 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3697A12D59F for ; Thu, 7 Apr 2016 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfWbS8FCe8bM for ; Thu, 7 Apr 2016 13:04:18 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E8612D141 for ; Thu, 7 Apr 2016 13:04:18 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id c4so113495328vkb.3 for ; Thu, 07 Apr 2016 13:04:18 -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; bh=rJwfowuab9R9GNxs8PEsKGJ4AteNF75JMK97oQZ8yrY=; b=FLipPdsPXiAfuUZv1AxOQ1PLfer4WH4RRdSxymiZpPPX0OkINMXCx8//GevZgB2n5W TQarPTTtMDLJeWluj5LczAzSudl6MRqBMj/Nnx8EID7I2zfuaw3SQ0tncs05AbspdYKE KXnCyMCdfnOuCwZiVjLdiAklqIbCMSwcV2nIHC8e3aNjJkoOV2v3cWwCJJfps0L1nIXw 4Lvzg6ml6HzGHBWDqHe0mDyzBlZSTqC4P6YTqgqJZ7aEdRUKA1Wpdd+WK3BEOkco8Zhd jG+VAYk/yC3tpd8zjh13qUvgXJ9oZ7velDavMzN3uUGcAgvQT26S8TrX/u+USdAkEk0g LYTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rJwfowuab9R9GNxs8PEsKGJ4AteNF75JMK97oQZ8yrY=; b=KZkG0yQ8/JBHI/ZajTz0z9TXI2lX8ZN+hHHkNC1oBy5qqsM8a0olXKQM779JOz+CqP 16SszAjNtWOjPyFbPPSnipkYhSGlKPsKkeCcdyqvYPnVRA+4SDciC9gWNb347nJYqRIn Zfl86d6EmOuTkBEl54SS0+Vx0qNJcf0S3b6iDBmRlCuijtKkx3lj0b94YWm4D5uJJLrG 61TXVo2co3chaJqJctY6aeOpZkeK06hs8io+7w7MbKJC7JsdBv/t2hobzhfa2h1D7hE0 ETFpM983Wou1YqiifRWilL4Ud8swdUa/lo/vQ8RqrojbH7/O6f/Yef13v9Ll6yUqpJa7 p+Ew== X-Gm-Message-State: AD7BkJKPFiklZmnvBM+f5dzKDlMl7/dyTsEUu4iUtjNbDeo3sXBypX0s5gA886/rR2B9Gw/tPreH38TDl50dqA== X-Received: by 10.176.65.33 with SMTP id j30mr2352769uad.142.1460059457863; Thu, 07 Apr 2016 13:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Thu, 7 Apr 2016 13:03:58 -0700 (PDT) From: Bernard Aboba Date: Thu, 7 Apr 2016 13:03:58 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=94eb2c124644564a92052fea95da Archived-At: Subject: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:04:20 -0000 --94eb2c124644564a92052fea95da Content-Type: text/plain; charset=UTF-8 In today's meeting, we had folks pointing to discussions of the meaning of the "lang" attribute in previous meetings (in MMUSIC). Can people post pointers to those previous discussions? --94eb2c124644564a92052fea95da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In today's meeting, we had folks pointing to discussio= ns of the meaning of the "lang" attribute in previous meetings (i= n MMUSIC).=C2=A0 Can people post pointers to those previous discussions? = =C2=A0
--94eb2c124644564a92052fea95da-- From nobody Thu Apr 7 13:08:57 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA94A12D59F for ; Thu, 7 Apr 2016 13:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHvZuQXnSUPi for ; Thu, 7 Apr 2016 13:08:51 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F45812D668 for ; Thu, 7 Apr 2016 13:08:51 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id k1so113710854vkb.0 for ; Thu, 07 Apr 2016 13:08:51 -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; bh=5zgJmySyZ835ekpaAPj7e6JmP5a7yQPMnUtCQ5o7NR8=; b=lBMv0k3Vx6aLdlNFc67e6/0yRsZoLW8oKnu65eLvmZtsJWBGuikjYSDK5bSYu2JbVl OLgWEV9wI+bOnriQ5jlzOW2oInw/57sfGMHXIq1+K8VNzxQrffn2MQM1AiqjyiMzgZom L9721ZBgHr4qoc6kOwbrz0PTmFpNzWbQIBxMdWqm1dhCh0icMCdc0Z2CchvKnW3XIM7w GiBigikD7H0Y7o4BWx8PGEueAmFPuivwZ8GjR6gdz6xkjSQZvI6vVk3AVF+5RLZsf/Ev 8BWSGBUvp7WGfrMU7nx9WFac1xPaMuiq65Fp6PUL2qn9Dw2F0Xq4cnYlG5li6SSNb/P6 EpIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5zgJmySyZ835ekpaAPj7e6JmP5a7yQPMnUtCQ5o7NR8=; b=Oy6yTN/GNGvWKWzQuBn5+8zQfK0W8pTMC3lYv6ie1ZuVGFi9AU/u8ZCRzSb3KUJ5IT bHXEQPqeAAaFHBQVDcDnOzFmdinVXcryJ925D+tHLYN9+M4HvJfT9d95+3O2XT0Tr5Ia jOojis9tuGn7WkPt0oFMAUPdIb927wIEO03JdLR2AVeLyjiLSXSq0WhvqsTCFYFdD630 OrLwb2qONvN7BnjUKznlCDtXfbaErbenOM3hAGclta5Gus8iK9UgZIEtGhK3ZXdn+JOf Q8PlfcwgibhFTBYILoZmabqFRNrZZ8uXplPPOp8blLxF7Dk60+5c8HJuCa4mafQAr6R2 h/Rw== X-Gm-Message-State: AD7BkJJ8drNIs59dCwBTMUt8eRxMTdweHCfrr0hIrGlpL7Wfkf89nvvbCH1OIFAmBaD/FLCW5/DGfadz983iNw== X-Received: by 10.31.6.130 with SMTP id 124mr2104538vkg.106.1460059730343; Thu, 07 Apr 2016 13:08:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Thu, 7 Apr 2016 13:08:30 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 7 Apr 2016 13:08:30 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a1143d39293ff63052feaa5b0 Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:08:53 -0000 --001a1143d39293ff63052feaa5b0 Content-Type: text/plain; charset=UTF-8 Here is what we have in RFC 4566bis ( https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): Multiple lang attributes can be provided either at session or media level if the session or media has capabilities to use multiple languages, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. As a session-level attribute, lang specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified. The "lang" attribute value must be a single [RFC5646 ] language tag in US-ASCII. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm. Events during the session can influence which language(s) are used, and the participants are not strictly bound to only use the declared languages. On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba wrote: > In today's meeting, we had folks pointing to discussions of the meaning of > the "lang" attribute in previous meetings (in MMUSIC). Can people post > pointers to those previous discussions? > --001a1143d39293ff63052feaa5b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is what we have in RFC 4566bis (https://tools.ie= tf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36):

   Multiple lang attributes can be provided either a=
t session or media
   level if the session or media has capabilities to use multiple
   languages, in which case the order of the attributes indicates the
   order of preference of the various languages in the session or media,
   from most preferred to least preferred.

   As a session-level attribute, lang specifies a language capability
   for the session being described.  As a media-level attribute, it
   specifies a language capability for that media, overriding any
   session-level language(s) specified.

   The "lang" attribute value must be =
a single [RFC5646] language tag in
   US-ASCII.  A "lang" attribute SHOULD be specified when a sessi=
on is
   of sufficient scope to cross geographic boundaries where the language
   of recipients cannot be assumed, or where the session has
   capabilities in languages different from the locally assumed norm.

   Events during the session can influence which language(s) are used,
   and the participants are not strictly bound to only use the declared
   languages.


On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba <bern= ard.aboba@gmail.com> wrote:
In today's meeting, we had folks pointing to discussi= ons of the meaning of the "lang" attribute in previous meetings (= in MMUSIC).=C2=A0 Can people post pointers to those previous discussions? = =C2=A0

--001a1143d39293ff63052feaa5b0-- From nobody Thu Apr 7 13:27:36 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EF012D6E4 for ; Thu, 7 Apr 2016 13:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-Mjnvd-39-s for ; Thu, 7 Apr 2016 13:27:29 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEBA12D6E3 for ; Thu, 7 Apr 2016 13:27:28 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u37KRPDm003144 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 7 Apr 2016 20:27:27 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u37KRPe0007867 for ; Thu, 7 Apr 2016 20:27:25 GMT MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from dhcp-ukc1-twvpn-1-vpnpool-10-175-171-236.vpn.oracle.com (dhcp-ukc1-twvpn-1-vpnpool-10-175-171-236.vpn.oracle.com [10.175.171.236]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 8.0.0.0.0 64bit (built Mar 19 2015)) with ESMTPSA id <0O5A00A5Q65E6B00@gotmail.us.oracle.com> for slim@ietf.org; Thu, 07 Apr 2016 13:27:22 -0700 (PDT) Date: Thu, 07 Apr 2016 17:27:08 -0300 From: Chris Newman To: slim@ietf.org Message-id: X-Mailer: Airmail (351) Content-transfer-encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Slim] draft meeting notes IETF 95 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:27:34 -0000 Slim WG Meeting Notes Note Taker: Chris Newman Presentation: draft-ietf-slim-multilang-content-00: Call for volunteers to help test multipart/multilingual on more clients (will repeat on list) * =C2=A0realistically need to support both message/rfc822 and message/glo= bal Target update for about mid-May draft-ietf-slim-negotiating-human-language-01: Randall: Changes to document were mostly clarifications. Declined to make changes that made the proposal more complex. Would really like to not add things. Some disagreement over how to interpret wording for lang attribute. draft-ietf-slim-use-cases-01: Updated today with some cleanup including proper references. Needs some quick review. Randy has sent comments on the document. Brian agreed to review document and comment. ETSI Statement (Gunnar): Q: If ETSI is publishing use cases, does the IET=46 need to publish a use case document=3F A: No reference to IET=46 use cases document by ETSI. Gunnar sent mail about ETSI use cases that are not well covered. comment overview: * Seen a number of grouping mechanisms in various ways, they're complicated and tend not to be implemented and don't seem to help as much as we thought they would. * The simpler we keep the document, the more likely it is to be implemented. That makes it easier to extend it based on real needs. The current lang attribute comment overview: * The current lang attribute is defined to cover content. There was previous agreement in a face2face that we could not use the existing attribute. * Order of importance has meaning for static media (e.g. newscast with multi-lingual content) * Would really like us to try to separate requirements from mechanisms. If we decide we have a requirement to do more complex cases then we need a mechanism. If we decide we don't have such a requirement, then we can have a simpler mechanism =3D Grouping preferences comment overview: * Don't think we have requirement to do grouping. Would prefer to start simple and go back later if we find we need the ability later. * can add grouping mechanism later. * don't think we need either order or grouping. * Don't believe we solve enough for the necessary use cases. The simple use cases can be done with the 'lang' attribute. The new attribute should handle the complex use cases so it's different. * Do we have a way of coming to consensus on which use cases are required vs. optional. Given that, can we reach consensus on if technology fits use cases. Chair: please send uses cases to list to update use cases along this line. comment overview: * need to see if we have rough consensus on simpler mechanism earlier. * extraneous media is not a problem. * In addition to getting right media, also need right resources, such as an interpreter. * that is not a signalling problem. From nobody Thu Apr 7 13:53:37 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1418612D55A for ; Thu, 7 Apr 2016 13:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT-YphQEQUNk for ; Thu, 7 Apr 2016 13:53:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 E617212D135 for ; Thu, 7 Apr 2016 13:53:33 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 8347E208D1F64; Thu, 7 Apr 2016 20:53:28 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37KrWrP031449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 20:53:32 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u37KrVDP023011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 22:53:32 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 22:53:31 +0200 From: "Drage, Keith (Nokia - GB)" To: EXT Chris Newman , "slim@ietf.org" Thread-Topic: [Slim] draft meeting notes IETF 95 Thread-Index: AQHRkQvvvfwBEj9K20GepI1doWPs359+/Fcg Date: Thu, 7 Apr 2016 20:53:31 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Slim] draft meeting notes IETF 95 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:53:36 -0000 SSBmaW5kIGl0IHVuYWNjZXB0YWJsZSB0aGF0IGEgZG9jdW1lbnQgZWRpdG9yIGlzIGFsbG93ZWQg dG8gbWFrZSBzdGF0ZW1lbnRzIGxpa2U6ICIgRGVjbGluZWQgdG8gbWFrZSBjaGFuZ2VzIHRoYXQg bWFkZSB0aGUgcHJvcG9zYWwgbW9yZSBjb21wbGV4LiBXb3VsZCByZWFsbHkgbGlrZSB0byBub3Qg YWRkIHRoaW5ncy4iIHdpdGhvdXQgZnVydGhlciBjbGFyaWZpY2F0aW9uIChhbmQgeWVzLCB0aGlz IGlzIHdoYXQgaGUgc2FpZCBiZWNhdXNlIEkgd2FzIGxpc3RlbmluZyByZW1vdGVseSkuDQoNClRo aXMgaXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUaGUgZWRpdG9yIG5lZWRzIHRvIHJlZmxl Y3QgdG8gd2lsbCBvZiB0aGUgd29ya2luZyBncm91cC4gSWYgdGhpbmdzIGFyZSBub3QgYWdyZWVk LCB0aGVuIGl0IG5lZWRzIHRvIGJlIHJlc29sdmVkIG9uIHRoZSBsaXN0LCBub3QgYnkgZGVjbGFy YXRpb24gb2Ygbm9uLWFjY2VwdGFuY2UgYnkgdGhlIGRvY3VtZW50IGVkaXRvci4NCg0KUmVnYXJk cw0KDQpLZWl0aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU0xJTSBbbWFp bHRvOnNsaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVYVCBDaHJpcyBOZXdtYW4N ClNlbnQ6IDA3IEFwcmlsIDIwMTYgMjE6MjcNClRvOiBzbGltQGlldGYub3JnDQpTdWJqZWN0OiBb U2xpbV0gZHJhZnQgbWVldGluZyBub3RlcyBJRVRGIDk1DQoNClNsaW0gV0cgTWVldGluZyBOb3Rl cw0KDQpOb3RlIFRha2VyOiBDaHJpcyBOZXdtYW4NCg0KUHJlc2VudGF0aW9uOiBkcmFmdC1pZXRm LXNsaW0tbXVsdGlsYW5nLWNvbnRlbnQtMDA6DQoNCkNhbGwgZm9yIHZvbHVudGVlcnMgdG8gaGVs cCB0ZXN0IG11bHRpcGFydC9tdWx0aWxpbmd1YWwgb24gbW9yZSBjbGllbnRzICh3aWxsIHJlcGVh dCBvbiBsaXN0KQ0KDQoqIMKgcmVhbGlzdGljYWxseSBuZWVkIHRvIHN1cHBvcnQgYm90aCBtZXNz YWdlL3JmYzgyMiBhbmQgbWVzc2FnZS9nbG9iYWwNCg0KVGFyZ2V0IHVwZGF0ZSBmb3IgYWJvdXQg bWlkLU1heQ0KDQpkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDE6 DQoNClJhbmRhbGw6IENoYW5nZXMgdG8gZG9jdW1lbnQgd2VyZSBtb3N0bHkgY2xhcmlmaWNhdGlv bnMuIERlY2xpbmVkIHRvIG1ha2UgY2hhbmdlcyB0aGF0IG1hZGUgdGhlIHByb3Bvc2FsIG1vcmUg Y29tcGxleC4gV291bGQgcmVhbGx5IGxpa2UgdG8gbm90IGFkZCB0aGluZ3MuIFNvbWUgZGlzYWdy ZWVtZW50IG92ZXIgaG93IHRvIGludGVycHJldCB3b3JkaW5nIGZvciBsYW5nIGF0dHJpYnV0ZS4N Cg0KZHJhZnQtaWV0Zi1zbGltLXVzZS1jYXNlcy0wMToNCg0KVXBkYXRlZCB0b2RheSB3aXRoIHNv bWUgY2xlYW51cCBpbmNsdWRpbmcgcHJvcGVyIHJlZmVyZW5jZXMuIE5lZWRzIHNvbWUgcXVpY2sg cmV2aWV3Lg0KDQpSYW5keSBoYXMgc2VudCBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQuDQpCcmlh biBhZ3JlZWQgdG8gcmV2aWV3IGRvY3VtZW50IGFuZCBjb21tZW50Lg0KDQpFVFNJIFN0YXRlbWVu dCAoR3VubmFyKToNCg0KUTogSWYgRVRTSSBpcyBwdWJsaXNoaW5nIHVzZSBjYXNlcywgZG9lcyB0 aGUgSUVURiBuZWVkIHRvIHB1Ymxpc2ggYSB1c2UgY2FzZSBkb2N1bWVudD8NCg0KQTogTm8gcmVm ZXJlbmNlIHRvIElFVEYgdXNlIGNhc2VzIGRvY3VtZW50IGJ5IEVUU0kuDQoNCkd1bm5hciBzZW50 IG1haWwgYWJvdXQgRVRTSSB1c2UgY2FzZXMgdGhhdCBhcmUgbm90IHdlbGwgY292ZXJlZC4NCg0K Y29tbWVudCBvdmVydmlldzoNCiogU2VlbiBhIG51bWJlciBvZiBncm91cGluZyBtZWNoYW5pc21z IGluIHZhcmlvdXMgd2F5cywgdGhleSdyZSBjb21wbGljYXRlZCBhbmQgdGVuZCBub3QgdG8gYmUg aW1wbGVtZW50ZWQgYW5kIGRvbid0IHNlZW0gdG8gaGVscCBhcyBtdWNoIGFzIHdlIHRob3VnaHQg dGhleSB3b3VsZC4NCiogVGhlIHNpbXBsZXIgd2Uga2VlcCB0aGUgZG9jdW1lbnQsIHRoZSBtb3Jl IGxpa2VseSBpdCBpcyB0byBiZSBpbXBsZW1lbnRlZC4gVGhhdCBtYWtlcyBpdCBlYXNpZXIgdG8g ZXh0ZW5kIGl0IGJhc2VkIG9uIHJlYWwgbmVlZHMuDQoNClRoZSBjdXJyZW50IGxhbmcgYXR0cmli dXRlDQoNCmNvbW1lbnQgb3ZlcnZpZXc6DQoqIFRoZSBjdXJyZW50IGxhbmcgYXR0cmlidXRlIGlz IGRlZmluZWQgdG8gY292ZXIgY29udGVudC4gVGhlcmUgd2FzIHByZXZpb3VzIGFncmVlbWVudCBp biBhIGZhY2UyZmFjZSB0aGF0IHdlIGNvdWxkIG5vdCB1c2UgdGhlIGV4aXN0aW5nIGF0dHJpYnV0 ZS4NCiogT3JkZXIgb2YgaW1wb3J0YW5jZSBoYXMgbWVhbmluZyBmb3Igc3RhdGljIG1lZGlhIChl LmcuIG5ld3NjYXN0IHdpdGggbXVsdGktbGluZ3VhbCBjb250ZW50KQ0KKiBXb3VsZCByZWFsbHkg bGlrZSB1cyB0byB0cnkgdG8gc2VwYXJhdGUgcmVxdWlyZW1lbnRzIGZyb20gbWVjaGFuaXNtcy4g SWYgd2UgZGVjaWRlIHdlIGhhdmUgYSByZXF1aXJlbWVudCB0byBkbyBtb3JlIGNvbXBsZXggY2Fz ZXMgdGhlbiB3ZSBuZWVkIGEgbWVjaGFuaXNtLiBJZiB3ZSBkZWNpZGUgd2UgZG9uJ3QgaGF2ZSBz dWNoIGEgcmVxdWlyZW1lbnQsIHRoZW4gd2UgY2FuIGhhdmUgYSBzaW1wbGVyIG1lY2hhbmlzbSA9 DQoNCkdyb3VwaW5nIHByZWZlcmVuY2VzDQoNCmNvbW1lbnQgb3ZlcnZpZXc6DQoqIERvbid0IHRo aW5rIHdlIGhhdmUgcmVxdWlyZW1lbnQgdG8gZG8gZ3JvdXBpbmcuIFdvdWxkIHByZWZlciB0byBz dGFydCBzaW1wbGUgYW5kIGdvIGJhY2sgbGF0ZXIgaWYgd2UgZmluZCB3ZSBuZWVkIHRoZSBhYmls aXR5IGxhdGVyLg0KKiBjYW4gYWRkIGdyb3VwaW5nIG1lY2hhbmlzbSBsYXRlci4NCiogZG9uJ3Qg dGhpbmsgd2UgbmVlZCBlaXRoZXIgb3JkZXIgb3IgZ3JvdXBpbmcuDQoqIERvbid0IGJlbGlldmUg d2Ugc29sdmUgZW5vdWdoIGZvciB0aGUgbmVjZXNzYXJ5IHVzZSBjYXNlcy4gVGhlIHNpbXBsZSB1 c2UgY2FzZXMgY2FuIGJlIGRvbmUgd2l0aCB0aGUgJ2xhbmcnIGF0dHJpYnV0ZS4gVGhlIG5ldyBh dHRyaWJ1dGUgc2hvdWxkIGhhbmRsZSB0aGUgY29tcGxleCB1c2UgY2FzZXMgc28gaXQncyBkaWZm ZXJlbnQuDQoqIERvIHdlIGhhdmUgYSB3YXkgb2YgY29taW5nIHRvIGNvbnNlbnN1cyBvbiB3aGlj aCB1c2UgY2FzZXMgYXJlIHJlcXVpcmVkIHZzLiBvcHRpb25hbC4gR2l2ZW4gdGhhdCwgY2FuIHdl IHJlYWNoIGNvbnNlbnN1cyBvbiBpZiB0ZWNobm9sb2d5IGZpdHMgdXNlIGNhc2VzLg0KDQpDaGFp cjogcGxlYXNlIHNlbmQgdXNlcyBjYXNlcyB0byBsaXN0IHRvIHVwZGF0ZSB1c2UgY2FzZXMgYWxv bmcgdGhpcyBsaW5lLg0KDQpjb21tZW50IG92ZXJ2aWV3Og0KKiBuZWVkIHRvIHNlZSBpZiB3ZSBo YXZlIHJvdWdoIGNvbnNlbnN1cyBvbiBzaW1wbGVyIG1lY2hhbmlzbSBlYXJsaWVyLg0KKiBleHRy YW5lb3VzIG1lZGlhIGlzIG5vdCBhIHByb2JsZW0uDQoqIEluIGFkZGl0aW9uIHRvIGdldHRpbmcg cmlnaHQgbWVkaWEsIGFsc28gbmVlZCByaWdodCByZXNvdXJjZXMsIHN1Y2ggYXMgYW4gaW50ZXJw cmV0ZXIuDQoqIHRoYXQgaXMgbm90IGEgc2lnbmFsbGluZyBwcm9ibGVtLg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNMSU0gbWFpbGluZyBs aXN0DQpTTElNQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NsaW0NCg== From nobody Thu Apr 7 13:53:52 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9274612D55A for ; Thu, 7 Apr 2016 13:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_T_M4Uu-Ktq for ; Thu, 7 Apr 2016 13:53:49 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B238312D135 for ; Thu, 7 Apr 2016 13:53:44 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id j35so74531536qge.0 for ; Thu, 07 Apr 2016 13:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=hZNApY9+1KgUqU+9zCTcBnIMasU/LtkQfbSx5yXxZCA=; b=1BT2k1nENoK3PqCFcp7E7n9VnoK1ETyFPUcGVE08Xblz1bWT4G4htRlpzJSsqf+joA FjwwLxMWmdhBxr3Stj5avOmMRLVfYuRl59mPqkh3TTeNy025vbh8i88Z8PJSVGLpT3SU uiqYvEgDjNVUsTb0vGxj13klY1Iscc+wjyVTEzWGW9OYplYlGrqYLoXRV95t/1GOccWd tcvTbzkoREvaYBVeiBu7VSWl81n88WFDL0JR9JiMtWO/YinmcJAXA3YKtHboJjlWbRRb ibyiqovKtkq6OyClHP1tJbROIgOuxbdcfgomYaxf7XpNimpVDn4VuBT5eYzz0x7pwtAF 8ubQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=hZNApY9+1KgUqU+9zCTcBnIMasU/LtkQfbSx5yXxZCA=; b=VC2Q15iGJmmHI9gkhSNlwHKPYXNmk/yZHFUiS7Vo/ai9hD+TmL8xScqSnyvACelgjz PGWvvDKdnbDGsblgcwoTxXyerLboF+ukREQT+C78JI4NrfN/eauq300ZPGpFHkRqxdoM 7TOT+zCL7/5dPn6xnzZ3znuvme+x6KIMVosZ5Z9T4Pq47OKY6hBrUvKr4HEmKdQAt03f qyHtvbzWydqtGacg7UobYFy2v5ts3T8OWEHzMSBUsipqAdMwGkVGGa3lFp85+3Ob/ixz k/+nLXT+gZ1EAa4vYLKZWiWg+m3tXIarAIlQSyk9Qh6xd4ytPZN7OCBQDSUYXuXqadyg ROWQ== X-Gm-Message-State: AD7BkJKD44Aniw2OYu5qjVROybjv3x0hZPmrZxLxel5HPJr70kVafiLN/23moTo9erKHSgZIGYyHc/NrbBY2wQ== MIME-Version: 1.0 X-Received: by 10.140.156.138 with SMTP id c132mr7111301qhc.96.1460062423777; Thu, 07 Apr 2016 13:53:43 -0700 (PDT) Received: by 10.55.155.212 with HTTP; Thu, 7 Apr 2016 13:53:43 -0700 (PDT) Date: Thu, 7 Apr 2016 21:53:43 +0100 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a113997661eb667052feb46a7 Archived-At: Subject: [Slim] Volunteers for direct multipart/multilingual email tests X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:53:51 -0000 --001a113997661eb667052feb46a7 Content-Type: text/plain; charset=UTF-8 Hi all, as I mentioned in the session today, I would like to do some wider testing of the suggested structure for multipart/multilingual email (eg, with message/rfc822 and message/global as inner parts). Please can you let me know if you want to help out with this and, if so, please let me know the email address for me to use. All I am after is an idea of how well your email clients handle the format and if there are any issues that could be addressed. The multilingual mail is likely to come from a different address to this one which is a restriction of the script I am using to send a hand-coded message. I will start sending some test emails in the next few days and I will try to send one to this group as well. Nik. -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a113997661eb667052feb46a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

as I mentioned in the session t= oday, I would like to do some wider testing of the suggested structure for = multipart/multilingual email (eg, with message/rfc822 and message/global as= inner parts).

Please can you let me know if you w= ant to help out with this and, if so, please let me know the email address = for me to use. All I am after is an idea of how well your email clients han= dle the format and if there are any issues that could be addressed.

The multilingual mail is likely to come from a different = address to this one which is a restriction of the script I am using to send= a hand-coded message.

I will start sending some t= est emails in the next few days and I will try to send one to this group as= well.

Nik.

-- 
-------------------------------------------------------=
----------
Multiple Language Content Type Internet Draft:
https://datatracker.ietf.org/doc/draft-ietf-= slim-multilangcontent/
-----------------------------------------------------------------=
--001a113997661eb667052feb46a7-- From nobody Thu Apr 7 14:03:43 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DE812D608 for ; Thu, 7 Apr 2016 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvGLAfvoYoxi for ; Thu, 7 Apr 2016 14:03:40 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF6212D665 for ; Thu, 7 Apr 2016 14:03:34 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o6so36375557qkc.2 for ; Thu, 07 Apr 2016 14:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jd/TSavl9Ea7y5ajops1EYf1dnqPbUmsvcwl0gXPrVE=; b=H6ErpvP2fKKoDdKBDHQzLcjSOMOBTLolCiLqGgfrqzNDyD5/S2e6Qvmacb5m4vCHIx LovhuEWjga+gugXUTgO4nkYUaFFFUdiHJsuFanfqsOLIgstQYSUs3YTUvRdY/j5mqRMl +wxOa8JKaZlbRxkaXT9GF6mf0EQIW7LoktzWuuYr1ph2pwJAl9+Tlq1+b1YqM8BABDAp k0uDjNdMb9ZR4JIGmU5B1k2PnKZR8hxD4Ipx+E5+fpBCwXZotTV/ub7NL5QNUVcNsU+2 tykAVrJJLyGsmvhUgUL5tE046LZTBRM6ky8Tg2n6gfeiTm3aCexjMVnjxxIZlpZlntoR hjCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jd/TSavl9Ea7y5ajops1EYf1dnqPbUmsvcwl0gXPrVE=; b=kVFb90LRZyCfCp03nfdNFWIG2pRV/QjHsmI0D8ehEy4EtD4rZ5FRjPfIXoysWWXfVg ALSVyeTp7Ky9yvoM8QMWE4W9K29V/jNsxhPwr35vyA4PJwAHbZZfvQczwnkcomF7LQUH GVy90VsiYCu8Tiy3LQMOWUk5BjztVXsMwuvbr4ytuDMLCvKD/PGKSDdW+pD94EKaWa9X YSnnzr/DfLPtpJjoCQffCAS6bb+Q095xKfg8NQQcXu/8r+ToEg78CBB3mmfHYRhvPn6l 69fKd13Ar8aaZoRYgiseY1MUQIZpCn8vExKkQuT0jAC6tu+GzLvhQUEaMOTkfBi0XTF6 bK0g== X-Gm-Message-State: AD7BkJJfY8qwoF0qyqE9gz2IT5aEn0QbP6UkWE4L9uNIZibPHr0iurIdXLj0ve4HTSS6vg== X-Received: by 10.55.20.88 with SMTP id e85mr6761044qkh.108.1460063013198; Thu, 07 Apr 2016 14:03:33 -0700 (PDT) Received: from jpanigra1-ltw7.cis.neustar.com ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id s75sm4167474qge.17.2016.04.07.14.03.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 14:03:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 7 Apr 2016 18:03:26 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "slim@ietf.org" , EXT Chris Newman Subject: Re: [Slim] draft meeting notes IETF 95 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:03:42 -0000 I took his statement to be that he didn=E2=80=99t make the change = because he didn=E2=80=99t think there was no consensus to do that. I = think we have rough consensus not do make that change. However, neither = of us can decide that. I certainly would hope that if there is = consensus, as determined by chairs, that he will make whatever changes = are needed to conform to that consensus. If he didn=E2=80=99t, then we = would have to have another editor, but I=E2=80=99m confident that = won=E2=80=99t be needed. I think it is VERY common for an editor not to make a change he = personally disagrees with until there is a consensus determination. I = see no issue here. Brian > On Apr 7, 2016, at 5:53 PM, Drage, Keith (Nokia - GB) = wrote: >=20 > I find it unacceptable that a document editor is allowed to make = statements like: " Declined to make changes that made the proposal more = complex. Would really like to not add things." without further = clarification (and yes, this is what he said because I was listening = remotely). >=20 > This is a working group document. The editor needs to reflect to will = of the working group. If things are not agreed, then it needs to be = resolved on the list, not by declaration of non-acceptance by the = document editor. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: SLIM [mailto:slim-bounces@ietf.org] On Behalf Of EXT Chris = Newman > Sent: 07 April 2016 21:27 > To: slim@ietf.org > Subject: [Slim] draft meeting notes IETF 95 >=20 > Slim WG Meeting Notes >=20 > Note Taker: Chris Newman >=20 > Presentation: draft-ietf-slim-multilang-content-00: >=20 > Call for volunteers to help test multipart/multilingual on more = clients (will repeat on list) >=20 > * realistically need to support both message/rfc822 and = message/global >=20 > Target update for about mid-May >=20 > draft-ietf-slim-negotiating-human-language-01: >=20 > Randall: Changes to document were mostly clarifications. Declined to = make changes that made the proposal more complex. Would really like to = not add things. Some disagreement over how to interpret wording for lang = attribute. >=20 > draft-ietf-slim-use-cases-01: >=20 > Updated today with some cleanup including proper references. Needs = some quick review. >=20 > Randy has sent comments on the document. > Brian agreed to review document and comment. >=20 > ETSI Statement (Gunnar): >=20 > Q: If ETSI is publishing use cases, does the IETF need to publish a = use case document? >=20 > A: No reference to IETF use cases document by ETSI. >=20 > Gunnar sent mail about ETSI use cases that are not well covered. >=20 > comment overview: > * Seen a number of grouping mechanisms in various ways, they're = complicated and tend not to be implemented and don't seem to help as = much as we thought they would. > * The simpler we keep the document, the more likely it is to be = implemented. That makes it easier to extend it based on real needs. >=20 > The current lang attribute >=20 > comment overview: > * The current lang attribute is defined to cover content. There was = previous agreement in a face2face that we could not use the existing = attribute. > * Order of importance has meaning for static media (e.g. newscast with = multi-lingual content) > * Would really like us to try to separate requirements from = mechanisms. If we decide we have a requirement to do more complex cases = then we need a mechanism. If we decide we don't have such a requirement, = then we can have a simpler mechanism =3D >=20 > Grouping preferences >=20 > comment overview: > * Don't think we have requirement to do grouping. Would prefer to = start simple and go back later if we find we need the ability later. > * can add grouping mechanism later. > * don't think we need either order or grouping. > * Don't believe we solve enough for the necessary use cases. The = simple use cases can be done with the 'lang' attribute. The new = attribute should handle the complex use cases so it's different. > * Do we have a way of coming to consensus on which use cases are = required vs. optional. Given that, can we reach consensus on if = technology fits use cases. >=20 > Chair: please send uses cases to list to update use cases along this = line. >=20 > comment overview: > * need to see if we have rough consensus on simpler mechanism earlier. > * extraneous media is not a problem. > * In addition to getting right media, also need right resources, such = as an interpreter. > * that is not a signalling problem. >=20 >=20 >=20 > _______________________________________________ > 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 Thu Apr 7 14:11:45 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B874112D5A9 for ; Thu, 7 Apr 2016 14:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SES6fSYKKn9s for ; Thu, 7 Apr 2016 14:11:41 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7B112D10C for ; Thu, 7 Apr 2016 14:11:38 -0700 (PDT) X-Halon-ID: 4ea6c7b2-fd05-11e5-88ba-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 7 Apr 2016 23:11:34 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5706CD04.4060707@omnitor.se> Date: Thu, 7 Apr 2016 23:11:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050400000904020508060101" Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:11:44 -0000 This is a multi-part message in MIME format. --------------050400000904020508060101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I had a discussion in mmusic in October 2015 under the subject: "Clarification for multiple lang attributes in rfc4566bis" Starting at: https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis /Gunnar Den 2016-04-07 kl. 22:08, skrev Bernard Aboba: > Here is what we have in RFC 4566bis > (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): > > Multiple lang attributes can be provided either at session or media > level if the session or media has capabilities to use multiple > languages, in which case the order of the attributes indicates the > order of preference of the various languages in the session or media, > from most preferred to least preferred. > > As a session-level attribute, lang specifies a language capability > for the session being described. As a media-level attribute, it > specifies a language capability for that media, overriding any > session-level language(s) specified. > The "lang" attribute value must be a single [RFC5646 ] language tag in > US-ASCII. A "lang" attribute SHOULD be specified when a session is > of sufficient scope to cross geographic boundaries where the language > of recipients cannot be assumed, or where the session has > capabilities in languages different from the locally assumed norm. > > Events during the session can influence which language(s) are used, > and the participants are not strictly bound to only use the declared > languages. > > > On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba > wrote: > > In today's meeting, we had folks pointing to discussions of the > meaning of the "lang" attribute in previous meetings (in MMUSIC). > Can people post pointers to those previous discussions? > > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------050400000904020508060101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I had a discussion in mmusic in October 2015 under the subject:
"Clarification for multiple lang attributes in rfc4566bis"
Starting at:
https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis

/Gunnar



Den 2016-04-07 kl. 22:08, skrev Bernard Aboba:
Here is what we have in RFC 4566bis (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): 

   Multiple lang attributes can be provided either at session or media
   level if the session or media has capabilities to use multiple
   languages, in which case the order of the attributes indicates the
   order of preference of the various languages in the session or media,
   from most preferred to least preferred.

   As a session-level attribute, lang specifies a language capability
   for the session being described.  As a media-level attribute, it
   specifies a language capability for that media, overriding any
   session-level language(s) specified.

   The "lang" attribute value must be a single [RFC5646] language tag in
   US-ASCII.  A "lang" attribute SHOULD be specified when a session is
   of sufficient scope to cross geographic boundaries where the language
   of recipients cannot be assumed, or where the session has
   capabilities in languages different from the locally assumed norm.

   Events during the session can influence which language(s) are used,
   and the participants are not strictly bound to only use the declared
   languages.


On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
In today's meeting, we had folks pointing to discussions of the meaning of the "lang" attribute in previous meetings (in MMUSIC).  Can people post pointers to those previous discussions?  



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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------050400000904020508060101-- From nobody Thu Apr 7 14:13:36 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDDE12D5A9 for ; Thu, 7 Apr 2016 14:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NswZWRKY5sMV for ; Thu, 7 Apr 2016 14:13:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8D9B012D10C for ; Thu, 7 Apr 2016 14:13:31 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 19BAB239B86F4; Thu, 7 Apr 2016 21:13:26 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u37LDTLG024435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 21:13:29 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u37LDSIm003424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 23:13:29 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 23:13:28 +0200 From: "Drage, Keith (Nokia - GB)" To: EXT Brian Rosen Thread-Topic: [Slim] draft meeting notes IETF 95 Thread-Index: AQHRkQvvvfwBEj9K20GepI1doWPs359+/Fcg///h5ACAACQE8A== Date: Thu, 7 Apr 2016 21:13:27 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEBC380@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "slim@ietf.org" , EXT Chris Newman Subject: Re: [Slim] draft meeting notes IETF 95 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:13:34 -0000 QWxsIEkgd291bGQgc2F5IGlzIHRoYXQgaXMgbm90IHdoYXQgaGUgc2FpZCBpbiB0aGUgbWVldGlu Zy4NCg0KSXQgd291bGQgbm90IGhhdmUgdGFrZW4gbXVjaCBlZmZvcnQgdG8gc2F5IChmcm9tIGVp dGhlciB0aGUgZWRpdG9yIG9yIHRoZSBjaGFpcnMpLCAiYnV0IHdlIHdpbGwgc2VlayBjb25zZW5z dXMgb24gdGhlIG1haWxpbmcgbGlzdCBjb25jZXJuaW5nIHRob3NlIGlzc3VlcyIuDQoNCktlaXRo DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFWFQgQnJpYW4gUm9zZW4gW21h aWx0bzpickBicmlhbnJvc2VuLm5ldF0gDQpTZW50OiAwNyBBcHJpbCAyMDE2IDIyOjAzDQpUbzog RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKQ0KQ2M6IEVYVCBDaHJpcyBOZXdtYW47IHNsaW1AaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbU2xpbV0gZHJhZnQgbWVldGluZyBub3RlcyBJRVRGIDk1DQoN CkkgdG9vayBoaXMgc3RhdGVtZW50IHRvIGJlIHRoYXQgaGUgZGlkbuKAmXQgbWFrZSB0aGUgY2hh bmdlIGJlY2F1c2UgaGUgZGlkbuKAmXQgdGhpbmsgdGhlcmUgd2FzIG5vIGNvbnNlbnN1cyB0byBk byB0aGF0LiAgSSB0aGluayB3ZSBoYXZlIHJvdWdoIGNvbnNlbnN1cyBub3QgZG8gbWFrZSB0aGF0 IGNoYW5nZS4gIEhvd2V2ZXIsIG5laXRoZXIgb2YgdXMgY2FuIGRlY2lkZSB0aGF0LiAgSSBjZXJ0 YWlubHkgd291bGQgaG9wZSB0aGF0IGlmIHRoZXJlIGlzIGNvbnNlbnN1cywgYXMgZGV0ZXJtaW5l ZCBieSBjaGFpcnMsIHRoYXQgaGUgd2lsbCBtYWtlIHdoYXRldmVyIGNoYW5nZXMgYXJlIG5lZWRl ZCB0byBjb25mb3JtIHRvIHRoYXQgY29uc2Vuc3VzLiAgSWYgaGUgZGlkbuKAmXQsIHRoZW4gd2Ug d291bGQgaGF2ZSB0byBoYXZlIGFub3RoZXIgZWRpdG9yLCBidXQgSeKAmW0gY29uZmlkZW50IHRo YXQgd29u4oCZdCBiZSBuZWVkZWQuDQoNCkkgdGhpbmsgaXQgaXMgVkVSWSBjb21tb24gZm9yIGFu IGVkaXRvciBub3QgdG8gbWFrZSBhIGNoYW5nZSBoZSBwZXJzb25hbGx5IGRpc2FncmVlcyB3aXRo IHVudGlsIHRoZXJlIGlzIGEgY29uc2Vuc3VzIGRldGVybWluYXRpb24uIEkgc2VlIG5vIGlzc3Vl IGhlcmUuDQoNCkJyaWFuDQoNCj4gT24gQXByIDcsIDIwMTYsIGF0IDU6NTMgUE0sIERyYWdlLCBL ZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5va2lhLmNvbT4gd3JvdGU6DQo+IA0KPiBJ IGZpbmQgaXQgdW5hY2NlcHRhYmxlIHRoYXQgYSBkb2N1bWVudCBlZGl0b3IgaXMgYWxsb3dlZCB0 byBtYWtlIHN0YXRlbWVudHMgbGlrZTogIiBEZWNsaW5lZCB0byBtYWtlIGNoYW5nZXMgdGhhdCBt YWRlIHRoZSBwcm9wb3NhbCBtb3JlIGNvbXBsZXguIFdvdWxkIHJlYWxseSBsaWtlIHRvIG5vdCBh ZGQgdGhpbmdzLiIgd2l0aG91dCBmdXJ0aGVyIGNsYXJpZmljYXRpb24gKGFuZCB5ZXMsIHRoaXMg aXMgd2hhdCBoZSBzYWlkIGJlY2F1c2UgSSB3YXMgbGlzdGVuaW5nIHJlbW90ZWx5KS4NCj4gDQo+ IFRoaXMgaXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUaGUgZWRpdG9yIG5lZWRzIHRvIHJl ZmxlY3QgdG8gd2lsbCBvZiB0aGUgd29ya2luZyBncm91cC4gSWYgdGhpbmdzIGFyZSBub3QgYWdy ZWVkLCB0aGVuIGl0IG5lZWRzIHRvIGJlIHJlc29sdmVkIG9uIHRoZSBsaXN0LCBub3QgYnkgZGVj bGFyYXRpb24gb2Ygbm9uLWFjY2VwdGFuY2UgYnkgdGhlIGRvY3VtZW50IGVkaXRvci4NCj4gDQo+ IFJlZ2FyZHMNCj4gDQo+IEtlaXRoDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBTTElNIFttYWlsdG86c2xpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RVhUIENocmlzIE5ld21hbg0KPiBTZW50OiAwNyBBcHJpbCAyMDE2IDIxOjI3DQo+IFRvOiBzbGlt QGlldGYub3JnDQo+IFN1YmplY3Q6IFtTbGltXSBkcmFmdCBtZWV0aW5nIG5vdGVzIElFVEYgOTUN Cj4gDQo+IFNsaW0gV0cgTWVldGluZyBOb3Rlcw0KPiANCj4gTm90ZSBUYWtlcjogQ2hyaXMgTmV3 bWFuDQo+IA0KPiBQcmVzZW50YXRpb246IGRyYWZ0LWlldGYtc2xpbS1tdWx0aWxhbmctY29udGVu dC0wMDoNCj4gDQo+IENhbGwgZm9yIHZvbHVudGVlcnMgdG8gaGVscCB0ZXN0IG11bHRpcGFydC9t dWx0aWxpbmd1YWwgb24gbW9yZSBjbGllbnRzICh3aWxsIHJlcGVhdCBvbiBsaXN0KQ0KPiANCj4g KiAgcmVhbGlzdGljYWxseSBuZWVkIHRvIHN1cHBvcnQgYm90aCBtZXNzYWdlL3JmYzgyMiBhbmQg bWVzc2FnZS9nbG9iYWwNCj4gDQo+IFRhcmdldCB1cGRhdGUgZm9yIGFib3V0IG1pZC1NYXkNCj4g DQo+IGRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS0wMToNCj4gDQo+ IFJhbmRhbGw6IENoYW5nZXMgdG8gZG9jdW1lbnQgd2VyZSBtb3N0bHkgY2xhcmlmaWNhdGlvbnMu IERlY2xpbmVkIHRvIG1ha2UgY2hhbmdlcyB0aGF0IG1hZGUgdGhlIHByb3Bvc2FsIG1vcmUgY29t cGxleC4gV291bGQgcmVhbGx5IGxpa2UgdG8gbm90IGFkZCB0aGluZ3MuIFNvbWUgZGlzYWdyZWVt ZW50IG92ZXIgaG93IHRvIGludGVycHJldCB3b3JkaW5nIGZvciBsYW5nIGF0dHJpYnV0ZS4NCj4g DQo+IGRyYWZ0LWlldGYtc2xpbS11c2UtY2FzZXMtMDE6DQo+IA0KPiBVcGRhdGVkIHRvZGF5IHdp dGggc29tZSBjbGVhbnVwIGluY2x1ZGluZyBwcm9wZXIgcmVmZXJlbmNlcy4gTmVlZHMgc29tZSBx dWljayByZXZpZXcuDQo+IA0KPiBSYW5keSBoYXMgc2VudCBjb21tZW50cyBvbiB0aGUgZG9jdW1l bnQuDQo+IEJyaWFuIGFncmVlZCB0byByZXZpZXcgZG9jdW1lbnQgYW5kIGNvbW1lbnQuDQo+IA0K PiBFVFNJIFN0YXRlbWVudCAoR3VubmFyKToNCj4gDQo+IFE6IElmIEVUU0kgaXMgcHVibGlzaGlu ZyB1c2UgY2FzZXMsIGRvZXMgdGhlIElFVEYgbmVlZCB0byBwdWJsaXNoIGEgdXNlIGNhc2UgZG9j dW1lbnQ/DQo+IA0KPiBBOiBObyByZWZlcmVuY2UgdG8gSUVURiB1c2UgY2FzZXMgZG9jdW1lbnQg YnkgRVRTSS4NCj4gDQo+IEd1bm5hciBzZW50IG1haWwgYWJvdXQgRVRTSSB1c2UgY2FzZXMgdGhh dCBhcmUgbm90IHdlbGwgY292ZXJlZC4NCj4gDQo+IGNvbW1lbnQgb3ZlcnZpZXc6DQo+ICogU2Vl biBhIG51bWJlciBvZiBncm91cGluZyBtZWNoYW5pc21zIGluIHZhcmlvdXMgd2F5cywgdGhleSdy ZSBjb21wbGljYXRlZCBhbmQgdGVuZCBub3QgdG8gYmUgaW1wbGVtZW50ZWQgYW5kIGRvbid0IHNl ZW0gdG8gaGVscCBhcyBtdWNoIGFzIHdlIHRob3VnaHQgdGhleSB3b3VsZC4NCj4gKiBUaGUgc2lt cGxlciB3ZSBrZWVwIHRoZSBkb2N1bWVudCwgdGhlIG1vcmUgbGlrZWx5IGl0IGlzIHRvIGJlIGlt cGxlbWVudGVkLiBUaGF0IG1ha2VzIGl0IGVhc2llciB0byBleHRlbmQgaXQgYmFzZWQgb24gcmVh bCBuZWVkcy4NCj4gDQo+IFRoZSBjdXJyZW50IGxhbmcgYXR0cmlidXRlDQo+IA0KPiBjb21tZW50 IG92ZXJ2aWV3Og0KPiAqIFRoZSBjdXJyZW50IGxhbmcgYXR0cmlidXRlIGlzIGRlZmluZWQgdG8g Y292ZXIgY29udGVudC4gVGhlcmUgd2FzIHByZXZpb3VzIGFncmVlbWVudCBpbiBhIGZhY2UyZmFj ZSB0aGF0IHdlIGNvdWxkIG5vdCB1c2UgdGhlIGV4aXN0aW5nIGF0dHJpYnV0ZS4NCj4gKiBPcmRl ciBvZiBpbXBvcnRhbmNlIGhhcyBtZWFuaW5nIGZvciBzdGF0aWMgbWVkaWEgKGUuZy4gbmV3c2Nh c3Qgd2l0aCBtdWx0aS1saW5ndWFsIGNvbnRlbnQpDQo+ICogV291bGQgcmVhbGx5IGxpa2UgdXMg dG8gdHJ5IHRvIHNlcGFyYXRlIHJlcXVpcmVtZW50cyBmcm9tIG1lY2hhbmlzbXMuIElmIHdlIGRl Y2lkZSB3ZSBoYXZlIGEgcmVxdWlyZW1lbnQgdG8gZG8gbW9yZSBjb21wbGV4IGNhc2VzIHRoZW4g d2UgbmVlZCBhIG1lY2hhbmlzbS4gSWYgd2UgZGVjaWRlIHdlIGRvbid0IGhhdmUgc3VjaCBhIHJl cXVpcmVtZW50LCB0aGVuIHdlIGNhbiBoYXZlIGEgc2ltcGxlciBtZWNoYW5pc20gPQ0KPiANCj4g R3JvdXBpbmcgcHJlZmVyZW5jZXMNCj4gDQo+IGNvbW1lbnQgb3ZlcnZpZXc6DQo+ICogRG9uJ3Qg dGhpbmsgd2UgaGF2ZSByZXF1aXJlbWVudCB0byBkbyBncm91cGluZy4gV291bGQgcHJlZmVyIHRv IHN0YXJ0IHNpbXBsZSBhbmQgZ28gYmFjayBsYXRlciBpZiB3ZSBmaW5kIHdlIG5lZWQgdGhlIGFi aWxpdHkgbGF0ZXIuDQo+ICogY2FuIGFkZCBncm91cGluZyBtZWNoYW5pc20gbGF0ZXIuDQo+ICog ZG9uJ3QgdGhpbmsgd2UgbmVlZCBlaXRoZXIgb3JkZXIgb3IgZ3JvdXBpbmcuDQo+ICogRG9uJ3Qg YmVsaWV2ZSB3ZSBzb2x2ZSBlbm91Z2ggZm9yIHRoZSBuZWNlc3NhcnkgdXNlIGNhc2VzLiBUaGUg c2ltcGxlIHVzZSBjYXNlcyBjYW4gYmUgZG9uZSB3aXRoIHRoZSAnbGFuZycgYXR0cmlidXRlLiBU aGUgbmV3IGF0dHJpYnV0ZSBzaG91bGQgaGFuZGxlIHRoZSBjb21wbGV4IHVzZSBjYXNlcyBzbyBp dCdzIGRpZmZlcmVudC4NCj4gKiBEbyB3ZSBoYXZlIGEgd2F5IG9mIGNvbWluZyB0byBjb25zZW5z dXMgb24gd2hpY2ggdXNlIGNhc2VzIGFyZSByZXF1aXJlZCB2cy4gb3B0aW9uYWwuIEdpdmVuIHRo YXQsIGNhbiB3ZSByZWFjaCBjb25zZW5zdXMgb24gaWYgdGVjaG5vbG9neSBmaXRzIHVzZSBjYXNl cy4NCj4gDQo+IENoYWlyOiBwbGVhc2Ugc2VuZCB1c2VzIGNhc2VzIHRvIGxpc3QgdG8gdXBkYXRl IHVzZSBjYXNlcyBhbG9uZyB0aGlzIGxpbmUuDQo+IA0KPiBjb21tZW50IG92ZXJ2aWV3Og0KPiAq IG5lZWQgdG8gc2VlIGlmIHdlIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uIHNpbXBsZXIgbWVjaGFu aXNtIGVhcmxpZXIuDQo+ICogZXh0cmFuZW91cyBtZWRpYSBpcyBub3QgYSBwcm9ibGVtLg0KPiAq IEluIGFkZGl0aW9uIHRvIGdldHRpbmcgcmlnaHQgbWVkaWEsIGFsc28gbmVlZCByaWdodCByZXNv dXJjZXMsIHN1Y2ggYXMgYW4gaW50ZXJwcmV0ZXIuDQo+ICogdGhhdCBpcyBub3QgYSBzaWduYWxs aW5nIHByb2JsZW0uDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFNMSU0gbWFpbGluZyBsaXN0DQo+IFNMSU1AaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNMSU0gbWFpbGluZyBs aXN0DQo+IFNMSU1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zbGltDQoNCg== From nobody Thu Apr 7 14:20:15 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A815512D6FB for ; Thu, 7 Apr 2016 14:20:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMHTVEv3tWul for ; Thu, 7 Apr 2016 14:20:10 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0665.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::665]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B387012D702 for ; Thu, 7 Apr 2016 14:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7InroFPmc1taj+5bot5Bw5xOMIDM29C2XaDb8mxxpc8=; b=fZdT1AZMD2aSUCBZYx/xljKBByO8cyVu8v5UMA8ayW6KddvS14DTUsk24DGjggIRCSY31c7zqMT05W8fjgsCvMpHirEBexy4qE7zNbA9uwV7sA3beArDH1WGAD/XwkhaerzHucPmqZGkR3jEmi7PGUClXVMaq88Uuun1MRa+ldE= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 21:19:52 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0453.027; Thu, 7 Apr 2016 21:19:52 +0000 From: Natasha Rooney To: "Drage, Keith (Nokia - GB)" Thread-Topic: [Slim] draft meeting notes IETF 95 Thread-Index: AQHRkQvtXXUZrf1JwU21Cx/EJCpxj59+/P2AgAACxgCAAALMgIAAAceA Date: Thu, 7 Apr 2016 21:19:52 +0000 Message-ID: <632127B0-9333-46A4-B18E-3B616597B56B@gsma.com> References: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEBC380@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEBC380@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.160.207] x-ms-office365-filtering-correlation-id: 7eaa7d5a-4880-4e0b-f4e5-08d35f2a5beb x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2064; 5:6T0YRm9nvH0xdN8dvjgFlngEaFnllXFMjqyo1nmrCqF94mpDU2jLPj4lV5BBe6LMX9i54obtX1lvj3YEt8pYMnDIeZM7RqXTCj+MdXAbUDgLFrWPBx0tdDP0dBi/g1oGVQz1FaVgp90ekm5vWxsmDQ==; 24:eoFicJ33lHdO/kutKcV1mUISkdCPHM+aadVGoaJzEDawgOuAAh6MzHjooSp6lelz3uxfwR1IaHhy891XQIqXO6HbtV/O3ydwoLg85PQycdE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2064; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR0401MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2064; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(13464003)(377454003)(586003)(16236675004)(5890100001)(11100500001)(4326007)(110136002)(1220700001)(5004730100002)(1096002)(76176999)(2906002)(102836003)(189998001)(3846002)(6116002)(50986999)(561944003)(36756003)(83716003)(5008740100001)(86362001)(5002640100001)(50226001)(15975445007)(66066001)(106116001)(122556002)(82746002)(92566002)(10400500002)(3280700002)(87936001)(19580395003)(19580405001)(77096005)(57306001)(3660700001)(33656002)(81166005)(2950100001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2064; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_632127B0933346A4B18E3B616597B56Bgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 21:19:52.3421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2064 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.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: 31.133.160.207 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: VI1PR0401MB2064.eurprd04.prod.outlook.com Archived-At: Cc: "slim@ietf.org" , EXT Chris Newman , EXT Brian Rosen Subject: Re: [Slim] draft meeting notes IETF 95 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:20:13 -0000 --_000_632127B0933346A4B18E3B616597B56Bgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBjaGFpciBJIHNob3VsZCBwZXJoYXBzIHRoZW4gcmVpdGVyYXRlIHRoYXQgd2UgcGxhbiB0 byBkbyB0aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCBJIHBsYW4gdG8gZ2V0IHRoaXMgZG9u ZSBuZXh0IHdlZWsuIFRoaXMgd2VlayBpcyBidXN5IGZvciBhIG51bWJlciBvZiB1cyBsZXTigJlz IHRha2UgYSBmZXcgZGF5cyB0byBkaWdlc3QsIGhhdmUgYSB0aGluaywgYW5kIGFkZHJlc3MgdGhp cyBvbiBsaXN0IG5leHQgd2Vlay4NCg0KQXBvbG9naWVzIGlmIEkgZGlkbuKAmXQgbWFrZSB0aGlz IGNsZWFyOyB0b28gbWFueSBCcml0aXNoIGNvbGxvcXVpYWxpc21zIHByb2JhYmx5IQ0KDQpBcyBh IHBhcnRpY2lwYW50IEkgYWdyZWUgd2l0aCBCcmlhbuKAmXMgaW50ZXJwcmV0YXRpb24gb2YgZXZl bnRzLiBJIGhhdmUgbm8gaXNzdWUgd2l0aCBubyBhY3Rpb24gb24gYmVoYWxmIG9mIHRoZSBlZGl0 b3IgYXMgdXAgdGlsbCBub3cgd2UgaGF2ZSBvbmx5IGhhZCBvYmplY3Rpb24gZnJvbSBvbmUgcGVy c29uLiBUbyBub3RlOiB3ZSB0YWtlIHRoZXNlIGNvbmNlcm5zIHNlcmlvdXNseSwgYnV0IGhhdmlu ZyBub3QgY29tZSB0byBhIHJlc29sdXRpb24gaXQgc2VlbXMgcmVhc29uYWJsZSBmb3Igbm8gYWN0 aW9uIHRvIGhhdmUgb2NjdXJyZWQgYXMgb2YgeWV0Lg0KDQpUaGFua3MhDQoNCk5hdGFzaGENCg0K DQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lzdCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICYg SUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8 ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3Nt Lm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0KDQoNCk9uIEFwciA3LCAyMDE2LCBhdCA2OjEz IFBNLCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIDxrZWl0aC5kcmFnZUBub2tpYS5jb208bWFp bHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbT4+IHdyb3RlOg0KDQpBbGwgSSB3b3VsZCBzYXkgaXMg dGhhdCBpcyBub3Qgd2hhdCBoZSBzYWlkIGluIHRoZSBtZWV0aW5nLg0KDQpJdCB3b3VsZCBub3Qg aGF2ZSB0YWtlbiBtdWNoIGVmZm9ydCB0byBzYXkgKGZyb20gZWl0aGVyIHRoZSBlZGl0b3Igb3Ig dGhlIGNoYWlycyksICJidXQgd2Ugd2lsbCBzZWVrIGNvbnNlbnN1cyBvbiB0aGUgbWFpbGluZyBs aXN0IGNvbmNlcm5pbmcgdGhvc2UgaXNzdWVzIi4NCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEVYVCBCcmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4u bmV0XQ0KU2VudDogMDcgQXByaWwgMjAxNiAyMjowMw0KVG86IERyYWdlLCBLZWl0aCAoTm9raWEg LSBHQikNCkNjOiBFWFQgQ2hyaXMgTmV3bWFuOyBzbGltQGlldGYub3JnPG1haWx0bzpzbGltQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtTbGltXSBkcmFmdCBtZWV0aW5nIG5vdGVzIElFVEYgOTUN Cg0KSSB0b29rIGhpcyBzdGF0ZW1lbnQgdG8gYmUgdGhhdCBoZSBkaWRu4oCZdCBtYWtlIHRoZSBj aGFuZ2UgYmVjYXVzZSBoZSBkaWRu4oCZdCB0aGluayB0aGVyZSB3YXMgbm8gY29uc2Vuc3VzIHRv IGRvIHRoYXQuICBJIHRoaW5rIHdlIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG5vdCBkbyBtYWtlIHRo YXQgY2hhbmdlLiAgSG93ZXZlciwgbmVpdGhlciBvZiB1cyBjYW4gZGVjaWRlIHRoYXQuICBJIGNl cnRhaW5seSB3b3VsZCBob3BlIHRoYXQgaWYgdGhlcmUgaXMgY29uc2Vuc3VzLCBhcyBkZXRlcm1p bmVkIGJ5IGNoYWlycywgdGhhdCBoZSB3aWxsIG1ha2Ugd2hhdGV2ZXIgY2hhbmdlcyBhcmUgbmVl ZGVkIHRvIGNvbmZvcm0gdG8gdGhhdCBjb25zZW5zdXMuICBJZiBoZSBkaWRu4oCZdCwgdGhlbiB3 ZSB3b3VsZCBoYXZlIHRvIGhhdmUgYW5vdGhlciBlZGl0b3IsIGJ1dCBJ4oCZbSBjb25maWRlbnQg dGhhdCB3b27igJl0IGJlIG5lZWRlZC4NCg0KSSB0aGluayBpdCBpcyBWRVJZIGNvbW1vbiBmb3Ig YW4gZWRpdG9yIG5vdCB0byBtYWtlIGEgY2hhbmdlIGhlIHBlcnNvbmFsbHkgZGlzYWdyZWVzIHdp dGggdW50aWwgdGhlcmUgaXMgYSBjb25zZW5zdXMgZGV0ZXJtaW5hdGlvbi4gSSBzZWUgbm8gaXNz dWUgaGVyZS4NCg0KQnJpYW4NCg0KT24gQXByIDcsIDIwMTYsIGF0IDU6NTMgUE0sIERyYWdlLCBL ZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5va2lhLmNvbTxtYWlsdG86a2VpdGguZHJh Z2VAbm9raWEuY29tPj4gd3JvdGU6DQoNCkkgZmluZCBpdCB1bmFjY2VwdGFibGUgdGhhdCBhIGRv Y3VtZW50IGVkaXRvciBpcyBhbGxvd2VkIHRvIG1ha2Ugc3RhdGVtZW50cyBsaWtlOiAiIERlY2xp bmVkIHRvIG1ha2UgY2hhbmdlcyB0aGF0IG1hZGUgdGhlIHByb3Bvc2FsIG1vcmUgY29tcGxleC4g V291bGQgcmVhbGx5IGxpa2UgdG8gbm90IGFkZCB0aGluZ3MuIiB3aXRob3V0IGZ1cnRoZXIgY2xh cmlmaWNhdGlvbiAoYW5kIHllcywgdGhpcyBpcyB3aGF0IGhlIHNhaWQgYmVjYXVzZSBJIHdhcyBs aXN0ZW5pbmcgcmVtb3RlbHkpLg0KDQpUaGlzIGlzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4g VGhlIGVkaXRvciBuZWVkcyB0byByZWZsZWN0IHRvIHdpbGwgb2YgdGhlIHdvcmtpbmcgZ3JvdXAu IElmIHRoaW5ncyBhcmUgbm90IGFncmVlZCwgdGhlbiBpdCBuZWVkcyB0byBiZSByZXNvbHZlZCBv biB0aGUgbGlzdCwgbm90IGJ5IGRlY2xhcmF0aW9uIG9mIG5vbi1hY2NlcHRhbmNlIGJ5IHRoZSBk b2N1bWVudCBlZGl0b3IuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFNMSU0gW21haWx0bzpzbGltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBFWFQgQ2hyaXMgTmV3bWFuDQpTZW50OiAwNyBBcHJpbCAyMDE2IDIxOjI3DQpUbzog c2xpbUBpZXRmLm9yZzxtYWlsdG86c2xpbUBpZXRmLm9yZz4NClN1YmplY3Q6IFtTbGltXSBkcmFm dCBtZWV0aW5nIG5vdGVzIElFVEYgOTUNCg0KU2xpbSBXRyBNZWV0aW5nIE5vdGVzDQoNCk5vdGUg VGFrZXI6IENocmlzIE5ld21hbg0KDQpQcmVzZW50YXRpb246IGRyYWZ0LWlldGYtc2xpbS1tdWx0 aWxhbmctY29udGVudC0wMDoNCg0KQ2FsbCBmb3Igdm9sdW50ZWVycyB0byBoZWxwIHRlc3QgbXVs dGlwYXJ0L211bHRpbGluZ3VhbCBvbiBtb3JlIGNsaWVudHMgKHdpbGwgcmVwZWF0IG9uIGxpc3Qp DQoNCiogIHJlYWxpc3RpY2FsbHkgbmVlZCB0byBzdXBwb3J0IGJvdGggbWVzc2FnZS9yZmM4MjIg YW5kIG1lc3NhZ2UvZ2xvYmFsDQoNClRhcmdldCB1cGRhdGUgZm9yIGFib3V0IG1pZC1NYXkNCg0K ZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFuLWxhbmd1YWdlLTAxOg0KDQpSYW5kYWxs OiBDaGFuZ2VzIHRvIGRvY3VtZW50IHdlcmUgbW9zdGx5IGNsYXJpZmljYXRpb25zLiBEZWNsaW5l ZCB0byBtYWtlIGNoYW5nZXMgdGhhdCBtYWRlIHRoZSBwcm9wb3NhbCBtb3JlIGNvbXBsZXguIFdv dWxkIHJlYWxseSBsaWtlIHRvIG5vdCBhZGQgdGhpbmdzLiBTb21lIGRpc2FncmVlbWVudCBvdmVy IGhvdyB0byBpbnRlcnByZXQgd29yZGluZyBmb3IgbGFuZyBhdHRyaWJ1dGUuDQoNCmRyYWZ0LWll dGYtc2xpbS11c2UtY2FzZXMtMDE6DQoNClVwZGF0ZWQgdG9kYXkgd2l0aCBzb21lIGNsZWFudXAg aW5jbHVkaW5nIHByb3BlciByZWZlcmVuY2VzLiBOZWVkcyBzb21lIHF1aWNrIHJldmlldy4NCg0K UmFuZHkgaGFzIHNlbnQgY29tbWVudHMgb24gdGhlIGRvY3VtZW50Lg0KQnJpYW4gYWdyZWVkIHRv IHJldmlldyBkb2N1bWVudCBhbmQgY29tbWVudC4NCg0KRVRTSSBTdGF0ZW1lbnQgKEd1bm5hcik6 DQoNClE6IElmIEVUU0kgaXMgcHVibGlzaGluZyB1c2UgY2FzZXMsIGRvZXMgdGhlIElFVEYgbmVl ZCB0byBwdWJsaXNoIGEgdXNlIGNhc2UgZG9jdW1lbnQ/DQoNCkE6IE5vIHJlZmVyZW5jZSB0byBJ RVRGIHVzZSBjYXNlcyBkb2N1bWVudCBieSBFVFNJLg0KDQpHdW5uYXIgc2VudCBtYWlsIGFib3V0 IEVUU0kgdXNlIGNhc2VzIHRoYXQgYXJlIG5vdCB3ZWxsIGNvdmVyZWQuDQoNCmNvbW1lbnQgb3Zl cnZpZXc6DQoqIFNlZW4gYSBudW1iZXIgb2YgZ3JvdXBpbmcgbWVjaGFuaXNtcyBpbiB2YXJpb3Vz IHdheXMsIHRoZXkncmUgY29tcGxpY2F0ZWQgYW5kIHRlbmQgbm90IHRvIGJlIGltcGxlbWVudGVk IGFuZCBkb24ndCBzZWVtIHRvIGhlbHAgYXMgbXVjaCBhcyB3ZSB0aG91Z2h0IHRoZXkgd291bGQu DQoqIFRoZSBzaW1wbGVyIHdlIGtlZXAgdGhlIGRvY3VtZW50LCB0aGUgbW9yZSBsaWtlbHkgaXQg aXMgdG8gYmUgaW1wbGVtZW50ZWQuIFRoYXQgbWFrZXMgaXQgZWFzaWVyIHRvIGV4dGVuZCBpdCBi YXNlZCBvbiByZWFsIG5lZWRzLg0KDQpUaGUgY3VycmVudCBsYW5nIGF0dHJpYnV0ZQ0KDQpjb21t ZW50IG92ZXJ2aWV3Og0KKiBUaGUgY3VycmVudCBsYW5nIGF0dHJpYnV0ZSBpcyBkZWZpbmVkIHRv IGNvdmVyIGNvbnRlbnQuIFRoZXJlIHdhcyBwcmV2aW91cyBhZ3JlZW1lbnQgaW4gYSBmYWNlMmZh Y2UgdGhhdCB3ZSBjb3VsZCBub3QgdXNlIHRoZSBleGlzdGluZyBhdHRyaWJ1dGUuDQoqIE9yZGVy IG9mIGltcG9ydGFuY2UgaGFzIG1lYW5pbmcgZm9yIHN0YXRpYyBtZWRpYSAoZS5nLiBuZXdzY2Fz dCB3aXRoIG11bHRpLWxpbmd1YWwgY29udGVudCkNCiogV291bGQgcmVhbGx5IGxpa2UgdXMgdG8g dHJ5IHRvIHNlcGFyYXRlIHJlcXVpcmVtZW50cyBmcm9tIG1lY2hhbmlzbXMuIElmIHdlIGRlY2lk ZSB3ZSBoYXZlIGEgcmVxdWlyZW1lbnQgdG8gZG8gbW9yZSBjb21wbGV4IGNhc2VzIHRoZW4gd2Ug bmVlZCBhIG1lY2hhbmlzbS4gSWYgd2UgZGVjaWRlIHdlIGRvbid0IGhhdmUgc3VjaCBhIHJlcXVp cmVtZW50LCB0aGVuIHdlIGNhbiBoYXZlIGEgc2ltcGxlciBtZWNoYW5pc20gPQ0KDQpHcm91cGlu ZyBwcmVmZXJlbmNlcw0KDQpjb21tZW50IG92ZXJ2aWV3Og0KKiBEb24ndCB0aGluayB3ZSBoYXZl IHJlcXVpcmVtZW50IHRvIGRvIGdyb3VwaW5nLiBXb3VsZCBwcmVmZXIgdG8gc3RhcnQgc2ltcGxl IGFuZCBnbyBiYWNrIGxhdGVyIGlmIHdlIGZpbmQgd2UgbmVlZCB0aGUgYWJpbGl0eSBsYXRlci4N CiogY2FuIGFkZCBncm91cGluZyBtZWNoYW5pc20gbGF0ZXIuDQoqIGRvbid0IHRoaW5rIHdlIG5l ZWQgZWl0aGVyIG9yZGVyIG9yIGdyb3VwaW5nLg0KKiBEb24ndCBiZWxpZXZlIHdlIHNvbHZlIGVu b3VnaCBmb3IgdGhlIG5lY2Vzc2FyeSB1c2UgY2FzZXMuIFRoZSBzaW1wbGUgdXNlIGNhc2VzIGNh biBiZSBkb25lIHdpdGggdGhlICdsYW5nJyBhdHRyaWJ1dGUuIFRoZSBuZXcgYXR0cmlidXRlIHNo b3VsZCBoYW5kbGUgdGhlIGNvbXBsZXggdXNlIGNhc2VzIHNvIGl0J3MgZGlmZmVyZW50Lg0KKiBE byB3ZSBoYXZlIGEgd2F5IG9mIGNvbWluZyB0byBjb25zZW5zdXMgb24gd2hpY2ggdXNlIGNhc2Vz IGFyZSByZXF1aXJlZCB2cy4gb3B0aW9uYWwuIEdpdmVuIHRoYXQsIGNhbiB3ZSByZWFjaCBjb25z ZW5zdXMgb24gaWYgdGVjaG5vbG9neSBmaXRzIHVzZSBjYXNlcy4NCg0KQ2hhaXI6IHBsZWFzZSBz ZW5kIHVzZXMgY2FzZXMgdG8gbGlzdCB0byB1cGRhdGUgdXNlIGNhc2VzIGFsb25nIHRoaXMgbGlu ZS4NCg0KY29tbWVudCBvdmVydmlldzoNCiogbmVlZCB0byBzZWUgaWYgd2UgaGF2ZSByb3VnaCBj b25zZW5zdXMgb24gc2ltcGxlciBtZWNoYW5pc20gZWFybGllci4NCiogZXh0cmFuZW91cyBtZWRp YSBpcyBub3QgYSBwcm9ibGVtLg0KKiBJbiBhZGRpdGlvbiB0byBnZXR0aW5nIHJpZ2h0IG1lZGlh LCBhbHNvIG5lZWQgcmlnaHQgcmVzb3VyY2VzLCBzdWNoIGFzIGFuIGludGVycHJldGVyLg0KKiB0 aGF0IGlzIG5vdCBhIHNpZ25hbGxpbmcgcHJvYmxlbS4NCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTTElNIG1haWxpbmcgbGlzdA0KU0xJTUBp ZXRmLm9yZzxtYWlsdG86U0xJTUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2xpbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClNMSU0gbWFpbGluZyBsaXN0DQpTTElNQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClNMSU0gbWFpbGluZyBsaXN0DQpTTElNQGlldGYub3Jn PG1haWx0bzpTTElNQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zbGltDQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRl ZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRo ZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNl ZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVh c2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5kIGhpZ2hs aWdodCB0aGUgZXJyb3IuDQo= --_000_632127B0933346A4B18E3B616597B56Bgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <58835D58AC841743A61924060419C90D@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQXMgYSBjaGFpciBJIHNob3VsZCBw ZXJoYXBzIHRoZW4gcmVpdGVyYXRlIHRoYXQgd2UgcGxhbiB0byBkbyB0aGlzIG9uIHRoZSBtYWls aW5nIGxpc3QsIGFuZCBJIHBsYW4gdG8gZ2V0IHRoaXMgZG9uZSBuZXh0IHdlZWsuIFRoaXMgd2Vl ayBpcyBidXN5IGZvciBhIG51bWJlciBvZiB1cyBsZXTigJlzIHRha2UgYSBmZXcgZGF5cyB0byBk aWdlc3QsIGhhdmUgYSB0aGluaywgYW5kIGFkZHJlc3MgdGhpcyBvbiBsaXN0IG5leHQgd2Vlay48 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNl aG9sZGVyIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpBcG9sb2dpZXMgaWYgSSBk aWRu4oCZdCBtYWtlIHRoaXMgY2xlYXI7IHRvbyBtYW55IEJyaXRpc2ggY29sbG9xdWlhbGlzbXMg cHJvYmFibHkhPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpBcyBhIHBhcnRp Y2lwYW50IEkgYWdyZWUgd2l0aCBCcmlhbuKAmXMgaW50ZXJwcmV0YXRpb24gb2YgZXZlbnRzLiBJ IGhhdmUgbm8gaXNzdWUgd2l0aCBubyBhY3Rpb24gb24gYmVoYWxmIG9mIHRoZSBlZGl0b3IgYXMg dXAgdGlsbCBub3cgd2UgaGF2ZSBvbmx5IGhhZCBvYmplY3Rpb24gZnJvbSBvbmUgcGVyc29uLiBU byBub3RlOiB3ZSB0YWtlIHRoZXNlIGNvbmNlcm5zIHNlcmlvdXNseSwgYnV0IGhhdmluZyBub3Qg Y29tZSB0byBhIHJlc29sdXRpb24NCiBpdCBzZWVtcyByZWFzb25hYmxlIGZvciBubyBhY3Rpb24g dG8gaGF2ZSBvY2N1cnJlZCBhcyBvZiB5ZXQuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyIgY2xhc3M9IiI+DQpUaGFua3MhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNo YTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9v bmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5i c3A7R1NNQSB8IDxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5y b29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhp c05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBj bGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgNywgMjAx NiwgYXQgNjoxMyBQTSwgRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbSIgY2xhc3M9IiI+a2VpdGguZHJhZ2VAbm9raWEuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QWxsIEkgd291bGQgc2F5IGlzIHRo YXQgaXMgbm90IHdoYXQgaGUgc2FpZCBpbiB0aGUgbWVldGluZy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJdCB3b3VsZCBub3QgaGF2ZSB0YWtlbiBtdWNoIGVmZm9ydCB0byBzYXkgKGZy b20gZWl0aGVyIHRoZSBlZGl0b3Igb3IgdGhlIGNoYWlycyksICZxdW90O2J1dCB3ZSB3aWxsIHNl ZWsgY29uc2Vuc3VzIG9uIHRoZSBtYWlsaW5nIGxpc3QgY29uY2VybmluZyB0aG9zZSBpc3N1ZXMm cXVvdDsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KS2VpdGg8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZy b206IEVYVCBCcmlhbiBSb3NlbiBbPGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0IiBj bGFzcz0iIj5tYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+XQ0KPGJyIGNsYXNzPSIiPg0KU2Vu dDogMDcgQXByaWwgMjAxNiAyMjowMzxiciBjbGFzcz0iIj4NClRvOiBEcmFnZSwgS2VpdGggKE5v a2lhIC0gR0IpPGJyIGNsYXNzPSIiPg0KQ2M6IEVYVCBDaHJpcyBOZXdtYW47IDxhIGhyZWY9Im1h aWx0bzpzbGltQGlldGYub3JnIiBjbGFzcz0iIj5zbGltQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NClN1YmplY3Q6IFJlOiBbU2xpbV0gZHJhZnQgbWVldGluZyBub3RlcyBJRVRGIDk1PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB0b29rIGhpcyBzdGF0ZW1lbnQgdG8gYmUgdGhhdCBo ZSBkaWRu4oCZdCBtYWtlIHRoZSBjaGFuZ2UgYmVjYXVzZSBoZSBkaWRu4oCZdCB0aGluayB0aGVy ZSB3YXMgbm8gY29uc2Vuc3VzIHRvIGRvIHRoYXQuICZuYnNwO0kgdGhpbmsgd2UgaGF2ZSByb3Vn aCBjb25zZW5zdXMgbm90IGRvIG1ha2UgdGhhdCBjaGFuZ2UuICZuYnNwO0hvd2V2ZXIsIG5laXRo ZXIgb2YgdXMgY2FuIGRlY2lkZSB0aGF0LiAmbmJzcDtJIGNlcnRhaW5seSB3b3VsZCBob3BlIHRo YXQgaWYgdGhlcmUgaXMNCiBjb25zZW5zdXMsIGFzIGRldGVybWluZWQgYnkgY2hhaXJzLCB0aGF0 IGhlIHdpbGwgbWFrZSB3aGF0ZXZlciBjaGFuZ2VzIGFyZSBuZWVkZWQgdG8gY29uZm9ybSB0byB0 aGF0IGNvbnNlbnN1cy4gJm5ic3A7SWYgaGUgZGlkbuKAmXQsIHRoZW4gd2Ugd291bGQgaGF2ZSB0 byBoYXZlIGFub3RoZXIgZWRpdG9yLCBidXQgSeKAmW0gY29uZmlkZW50IHRoYXQgd29u4oCZdCBi ZSBuZWVkZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB0aGluayBpdCBpcyBWRVJZ IGNvbW1vbiBmb3IgYW4gZWRpdG9yIG5vdCB0byBtYWtlIGEgY2hhbmdlIGhlIHBlcnNvbmFsbHkg ZGlzYWdyZWVzIHdpdGggdW50aWwgdGhlcmUgaXMgYSBjb25zZW5zdXMgZGV0ZXJtaW5hdGlvbi4g SSBzZWUgbm8gaXNzdWUgaGVyZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCcmlhbjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPk9uIEFwciA3LCAyMDE2LCBhdCA1OjUzIFBNLCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0Ip ICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguZHJhZ2VAbm9raWEuY29tIiBjbGFzcz0iIj5rZWl0 aC5kcmFnZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJIGZpbmQgaXQgdW5hY2NlcHRhYmxlIHRoYXQgYSBkb2N1bWVudCBlZGl0b3IgaXMgYWxs b3dlZCB0byBtYWtlIHN0YXRlbWVudHMgbGlrZTogJnF1b3Q7IERlY2xpbmVkIHRvIG1ha2UgY2hh bmdlcyB0aGF0IG1hZGUgdGhlIHByb3Bvc2FsIG1vcmUgY29tcGxleC4gV291bGQgcmVhbGx5IGxp a2UgdG8gbm90IGFkZCB0aGluZ3MuJnF1b3Q7IHdpdGhvdXQgZnVydGhlciBjbGFyaWZpY2F0aW9u IChhbmQgeWVzLCB0aGlzIGlzIHdoYXQgaGUgc2FpZCBiZWNhdXNlIEkgd2FzDQogbGlzdGVuaW5n IHJlbW90ZWx5KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGlzIGEgd29ya2lu ZyBncm91cCBkb2N1bWVudC4gVGhlIGVkaXRvciBuZWVkcyB0byByZWZsZWN0IHRvIHdpbGwgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAuIElmIHRoaW5ncyBhcmUgbm90IGFncmVlZCwgdGhlbiBpdCBuZWVk cyB0byBiZSByZXNvbHZlZCBvbiB0aGUgbGlzdCwgbm90IGJ5IGRlY2xhcmF0aW9uIG9mIG5vbi1h Y2NlcHRhbmNlIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KUmVnYXJkczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCktlaXRoPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9 IiI+DQpGcm9tOiBTTElNIFs8YSBocmVmPSJtYWlsdG86c2xpbS1ib3VuY2VzQGlldGYub3JnIiBj bGFzcz0iIj5tYWlsdG86c2xpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEVY VCBDaHJpcyBOZXdtYW48YnIgY2xhc3M9IiI+DQpTZW50OiAwNyBBcHJpbCAyMDE2IDIxOjI3PGJy IGNsYXNzPSIiPg0KVG86IDxhIGhyZWY9Im1haWx0bzpzbGltQGlldGYub3JnIiBjbGFzcz0iIj5z bGltQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NClN1YmplY3Q6IFtTbGltXSBkcmFmdCBtZWV0 aW5nIG5vdGVzIElFVEYgOTU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbGltIFdHIE1l ZXRpbmcgTm90ZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOb3RlIFRha2VyOiBDaHJp cyBOZXdtYW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQcmVzZW50YXRpb246IGRyYWZ0 LWlldGYtc2xpbS1tdWx0aWxhbmctY29udGVudC0wMDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpDYWxsIGZvciB2b2x1bnRlZXJzIHRvIGhlbHAgdGVzdCBtdWx0aXBhcnQvbXVsdGlsaW5n dWFsIG9uIG1vcmUgY2xpZW50cyAod2lsbCByZXBlYXQgb24gbGlzdCk8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQoqICZuYnNwO3JlYWxpc3RpY2FsbHkgbmVlZCB0byBzdXBwb3J0IGJvdGgg bWVzc2FnZS9yZmM4MjIgYW5kIG1lc3NhZ2UvZ2xvYmFsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KVGFyZ2V0IHVwZGF0ZSBmb3IgYWJvdXQgbWlkLU1heTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCmRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZS0wMTo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSYW5kYWxsOiBDaGFuZ2VzIHRvIGRvY3VtZW50 IHdlcmUgbW9zdGx5IGNsYXJpZmljYXRpb25zLiBEZWNsaW5lZCB0byBtYWtlIGNoYW5nZXMgdGhh dCBtYWRlIHRoZSBwcm9wb3NhbCBtb3JlIGNvbXBsZXguIFdvdWxkIHJlYWxseSBsaWtlIHRvIG5v dCBhZGQgdGhpbmdzLiBTb21lIGRpc2FncmVlbWVudCBvdmVyIGhvdyB0byBpbnRlcnByZXQgd29y ZGluZyBmb3IgbGFuZyBhdHRyaWJ1dGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KZHJh ZnQtaWV0Zi1zbGltLXVzZS1jYXNlcy0wMTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpV cGRhdGVkIHRvZGF5IHdpdGggc29tZSBjbGVhbnVwIGluY2x1ZGluZyBwcm9wZXIgcmVmZXJlbmNl cy4gTmVlZHMgc29tZSBxdWljayByZXZpZXcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K UmFuZHkgaGFzIHNlbnQgY29tbWVudHMgb24gdGhlIGRvY3VtZW50LjxiciBjbGFzcz0iIj4NCkJy aWFuIGFncmVlZCB0byByZXZpZXcgZG9jdW1lbnQgYW5kIGNvbW1lbnQuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KRVRTSSBTdGF0ZW1lbnQgKEd1bm5hcik6PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KUTogSWYgRVRTSSBpcyBwdWJsaXNoaW5nIHVzZSBjYXNlcywgZG9lcyB0aGUg SUVURiBuZWVkIHRvIHB1Ymxpc2ggYSB1c2UgY2FzZSBkb2N1bWVudD88YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpBOiBObyByZWZlcmVuY2UgdG8gSUVURiB1c2UgY2FzZXMgZG9jdW1lbnQg YnkgRVRTSS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpHdW5uYXIgc2VudCBtYWlsIGFi b3V0IEVUU0kgdXNlIGNhc2VzIHRoYXQgYXJlIG5vdCB3ZWxsIGNvdmVyZWQuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KY29tbWVudCBvdmVydmlldzo8YnIgY2xhc3M9IiI+DQoqIFNlZW4g YSBudW1iZXIgb2YgZ3JvdXBpbmcgbWVjaGFuaXNtcyBpbiB2YXJpb3VzIHdheXMsIHRoZXkncmUg Y29tcGxpY2F0ZWQgYW5kIHRlbmQgbm90IHRvIGJlIGltcGxlbWVudGVkIGFuZCBkb24ndCBzZWVt IHRvIGhlbHAgYXMgbXVjaCBhcyB3ZSB0aG91Z2h0IHRoZXkgd291bGQuPGJyIGNsYXNzPSIiPg0K KiBUaGUgc2ltcGxlciB3ZSBrZWVwIHRoZSBkb2N1bWVudCwgdGhlIG1vcmUgbGlrZWx5IGl0IGlz IHRvIGJlIGltcGxlbWVudGVkLiBUaGF0IG1ha2VzIGl0IGVhc2llciB0byBleHRlbmQgaXQgYmFz ZWQgb24gcmVhbCBuZWVkcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgY3VycmVu dCBsYW5nIGF0dHJpYnV0ZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmNvbW1lbnQgb3Zl cnZpZXc6PGJyIGNsYXNzPSIiPg0KKiBUaGUgY3VycmVudCBsYW5nIGF0dHJpYnV0ZSBpcyBkZWZp bmVkIHRvIGNvdmVyIGNvbnRlbnQuIFRoZXJlIHdhcyBwcmV2aW91cyBhZ3JlZW1lbnQgaW4gYSBm YWNlMmZhY2UgdGhhdCB3ZSBjb3VsZCBub3QgdXNlIHRoZSBleGlzdGluZyBhdHRyaWJ1dGUuPGJy IGNsYXNzPSIiPg0KKiBPcmRlciBvZiBpbXBvcnRhbmNlIGhhcyBtZWFuaW5nIGZvciBzdGF0aWMg bWVkaWEgKGUuZy4gbmV3c2Nhc3Qgd2l0aCBtdWx0aS1saW5ndWFsIGNvbnRlbnQpPGJyIGNsYXNz PSIiPg0KKiBXb3VsZCByZWFsbHkgbGlrZSB1cyB0byB0cnkgdG8gc2VwYXJhdGUgcmVxdWlyZW1l bnRzIGZyb20gbWVjaGFuaXNtcy4gSWYgd2UgZGVjaWRlIHdlIGhhdmUgYSByZXF1aXJlbWVudCB0 byBkbyBtb3JlIGNvbXBsZXggY2FzZXMgdGhlbiB3ZSBuZWVkIGEgbWVjaGFuaXNtLiBJZiB3ZSBk ZWNpZGUgd2UgZG9uJ3QgaGF2ZSBzdWNoIGEgcmVxdWlyZW1lbnQsIHRoZW4gd2UgY2FuIGhhdmUg YSBzaW1wbGVyIG1lY2hhbmlzbSA9PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KR3JvdXBp bmcgcHJlZmVyZW5jZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpjb21tZW50IG92ZXJ2 aWV3OjxiciBjbGFzcz0iIj4NCiogRG9uJ3QgdGhpbmsgd2UgaGF2ZSByZXF1aXJlbWVudCB0byBk byBncm91cGluZy4gV291bGQgcHJlZmVyIHRvIHN0YXJ0IHNpbXBsZSBhbmQgZ28gYmFjayBsYXRl ciBpZiB3ZSBmaW5kIHdlIG5lZWQgdGhlIGFiaWxpdHkgbGF0ZXIuPGJyIGNsYXNzPSIiPg0KKiBj YW4gYWRkIGdyb3VwaW5nIG1lY2hhbmlzbSBsYXRlci48YnIgY2xhc3M9IiI+DQoqIGRvbid0IHRo aW5rIHdlIG5lZWQgZWl0aGVyIG9yZGVyIG9yIGdyb3VwaW5nLjxiciBjbGFzcz0iIj4NCiogRG9u J3QgYmVsaWV2ZSB3ZSBzb2x2ZSBlbm91Z2ggZm9yIHRoZSBuZWNlc3NhcnkgdXNlIGNhc2VzLiBU aGUgc2ltcGxlIHVzZSBjYXNlcyBjYW4gYmUgZG9uZSB3aXRoIHRoZSAnbGFuZycgYXR0cmlidXRl LiBUaGUgbmV3IGF0dHJpYnV0ZSBzaG91bGQgaGFuZGxlIHRoZSBjb21wbGV4IHVzZSBjYXNlcyBz byBpdCdzIGRpZmZlcmVudC48YnIgY2xhc3M9IiI+DQoqIERvIHdlIGhhdmUgYSB3YXkgb2YgY29t aW5nIHRvIGNvbnNlbnN1cyBvbiB3aGljaCB1c2UgY2FzZXMgYXJlIHJlcXVpcmVkIHZzLiBvcHRp b25hbC4gR2l2ZW4gdGhhdCwgY2FuIHdlIHJlYWNoIGNvbnNlbnN1cyBvbiBpZiB0ZWNobm9sb2d5 IGZpdHMgdXNlIGNhc2VzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNoYWlyOiBwbGVh c2Ugc2VuZCB1c2VzIGNhc2VzIHRvIGxpc3QgdG8gdXBkYXRlIHVzZSBjYXNlcyBhbG9uZyB0aGlz IGxpbmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KY29tbWVudCBvdmVydmlldzo8YnIg Y2xhc3M9IiI+DQoqIG5lZWQgdG8gc2VlIGlmIHdlIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uIHNp bXBsZXIgbWVjaGFuaXNtIGVhcmxpZXIuPGJyIGNsYXNzPSIiPg0KKiBleHRyYW5lb3VzIG1lZGlh IGlzIG5vdCBhIHByb2JsZW0uPGJyIGNsYXNzPSIiPg0KKiBJbiBhZGRpdGlvbiB0byBnZXR0aW5n IHJpZ2h0IG1lZGlhLCBhbHNvIG5lZWQgcmlnaHQgcmVzb3VyY2VzLCBzdWNoIGFzIGFuIGludGVy cHJldGVyLjxiciBjbGFzcz0iIj4NCiogdGhhdCBpcyBub3QgYSBzaWduYWxsaW5nIHByb2JsZW0u PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xh c3M9IiI+DQpTTElNIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpT TElNQGlldGYub3JnIiBjbGFzcz0iIj5TTElNQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbTxiciBjbGFzcz0iIj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KU0xJTSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpTTElNQGlldGYub3JnPGJyIGNsYXNz PSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTTElNIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpTTElNQGlldGYub3JnIiBjbGFzcz0iIj5T TElNQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2xpbTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws c2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xvcjojOTk5OTk5OyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5OyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1p bm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDs7IG1zby1h bnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLUdCOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBp bnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwu IElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlv biBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25l OyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICYjNDM7NDQgMjA3IDM1NiAwNjAw DQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48L3A+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_632127B0933346A4B18E3B616597B56Bgsmacom_-- From nobody Thu Apr 7 14:40:24 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5064E12D1B8 for ; Thu, 7 Apr 2016 14:40:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT_KSJ4rbtDW for ; Thu, 7 Apr 2016 14:40:22 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9D212D10C for ; Thu, 7 Apr 2016 14:40:22 -0700 (PDT) Received: from dhcp-93ce.meeting.ietf.org (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 7 Apr 2016 14:40:21 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 7 Apr 2016 14:40:17 -0700 To: Bernard Aboba , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:40:23 -0000 At 1:03 PM -0700 4/7/16, Bernard Aboba wrote: > In today's meeting, we had folks pointing to discussions of the > meaning of the "lang" attribute in previous meetings (in MMUSIC). > Can people post pointers to those previous discussions? There were various ad-hoc discussions going back a number of years. I'd have to do a search of my email archives to find them all, but I do have notes from a meeting in 2013 where some combination of the following people attended (all of whom indicated interest in participating; I sent notes from the discussion to all of them, but didn't note who was there): Peter Saint-Andre, Flemming Andreasen, Gunnar Hellstrom, Brian Rosen, Keith Drage, Peter Saint-Andre, Brian Rosen, Hannes Tschofenig, Ari Keranen, Alexey Melnikov, John C Klensin, Harald Alvestrand, Andrew Hutton, Pete Resnick, Dale Worley, Randall Gellens. The notes indicate that we agreed that: New SDP attribute(s) vs re-use of existing 'lang' attribute: - Existing attribute semantics are unclear so should be avoided - Minting new attributes is cheap -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- C++ is pronounced "C cross cross." Not one but two crosses to bear: C and a broken interpretation of object-orientation. From nobody Thu Apr 7 15:19:07 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B7212D154 for ; Thu, 7 Apr 2016 15:19:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nASH-pH3Gs3Z for ; Thu, 7 Apr 2016 15:19:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 082D612D0BF for ; Thu, 7 Apr 2016 15:19:05 -0700 (PDT) Received: from dhcp-93ce.meeting.ietf.org (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 7 Apr 2016 15:19:03 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADEBC2F2@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Thu, 7 Apr 2016 15:18:58 -0700 To: "Drage, Keith (Nokia - GB)" , EXT Chris Newman , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] draft meeting notes IETF 95 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:19:06 -0000 At 8:53 PM +0000 4/7/16, Keith (Nokia - GB) Drage wrote: > I find it unacceptable that a document editor is allowed to make > statements like: " Declined to make changes that made the proposal > more complex. Would really like to not add things." without further > clarification (and yes, this is what he said because I was > listening remotely). I apologize for being terse. What I meant was that I declined to unilaterally add complexity based on a single request. Of course if we have WG consensus to make changes, I will do so (and would expect to be removed as document editor if I failed to do so). Keith, we've worked together in the IETF for many, many years. I'm surprised that you would think I meant what you wrote. > This is a working group document. The editor needs to reflect to > will of the working group. If things are not agreed, then it needs > to be resolved on the list, not by declaration of non-acceptance by > the document editor. This is exactly the point Brian raised: we need to determine if we have rough consensus to keep the mechanism simple or not. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Never call a man a fool. Borrow from him. From nobody Thu Apr 7 15:26:46 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B908812D73E for ; Thu, 7 Apr 2016 15:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N866z_15CKQW for ; Thu, 7 Apr 2016 15:26:40 -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 9A1CD12D73D for ; Thu, 7 Apr 2016 15:26:37 -0700 (PDT) X-Halon-ID: c31e7c2b-fd0f-11e5-aff0-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 8 Apr 2016 00:26:24 +0200 (CEST) To: Randall Gellens , Natasha Rooney References: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5706DE97.3030500@omnitor.se> Date: Fri, 8 Apr 2016 00:26:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:26:44 -0000 Randall, Sadly very few of your change proposals for the use case document matches my view of the needs we have and the requirements they raise. See comments below. Den 2016-04-07 kl. 20:29, skrev Randall Gellens: > > ---------- > Use case 2.4, change the text: > > Old: > An answering service will have no guidance to which is > the preferred modality and may select to use the modality that is > the callers last resort even if the preferred alternative is > available. > > To: > An answering service will have no guidance to which is > the preferred modality and thus all supported modalities > might be set up. The caller and answerer then use the > preferred modalities and ignore the non-preferred ones. Not acceptable. The users need guidance about how to start the session as humans, not just which media to enable. If the answerer starts with the last resort language/modality but can do the preferred, the caller may get the wrong impression that the last resort needs to be used and there will be a long confusion before they sort out the most efficient way to communicate. There is also a need to differentiate this case when just one language/modality is needed from the cases when both language/modalities are required. And it is a way for the answering part who happen to have a terminal only supporting the caller's last resort that it is ok to answer with that. The caller would not to announce the capability if it would mean that it was on same prerference level as the preferred language /modality. Conclusion: Priority declaration across m-lines is required. > > The text: > > Old: > In order to not miss any > calls, the indication of text as last resort would be desirable. > > o Solution: need coding of an absolute preference: hi, med, lo > together with the tag. > > Should be deleted. An absolute preference is not needed. The worst > case outcome is that unused media streams are established. Not acceptable. see reasoning above. Maybe absolute preference is not the correct requirement. Preference level regardless of m-line is maybe more appropriate description. > > ---------- > In use case 2.5, replace the text: > > Old: > (There is no current solution that says that the > text path is important. The answering part may see it as an > alternative.) > > o Solution: Need for preference indication per modality > > New: > Both modalities are established, and used as preferred by the humans. > > o Solution: Possible > Not acceptable. The text answer path is very strongly preferred. The voice answer path is just appreciated. The answering part should not just aswer by voice phone and ignore the text need. Coding of a clear preference for getting the text included is needed. > ---------- > Use case 2.5.1, replace the text: > > Old: > There currently are methods to indicate that the call shall fail if a > language is not met, but that may be too drastic for some users > including the one in the above scenario (Section 2.5). It may be > important to be able to connect and just say something, or use > residual hearing to get something back when the voice is familiar. > o Possible solution: coding of an absolute preference together with > the tag could solve this case if used together with the > directional indications. For example: > > "preference: hi, med, lo" > > Another solution would be to indicate required grouping of media, > however this raises the complexity level. > > New: > There currently are methods to indicate if the call should fail > or proceed when no languages are in common. In situations such > as the above scenario (Section 2.5), it may be important to be > able to connect and just say something, or use residual hearing > to get something back when the voice is familiar. With emergency > calls, it is useful for the PSAP call taker to be able to hear > background and anciliary sounds even if unable to speak to the > caller. > > o Solution: Possible Yes maybe. This is rather an indication that the current * parameter is nearly always needed, and should possibly be the default. > > ---------- > In use case 2.6, change: > > OLD: > direction and find the only possible combination. > > o Solution: Need for preference indication per modality > > New: > direction and find possible combinations. > > o Solution: Possible Not acceptable. It is possible only in the simple case when only one language in each direction is declared. But if the caller want to indicate: I strongly want to speak, and get text back, but I can also as the last resort type and get text back, then it is important to get the preferred alternative combination on high priority. > > ---------- > Use cases 2.7, 2.8: > > Delete "and absolute level of preference indication" from Solution. Not acceptable. They are needed. > > ---------- > Section 3: > > Typo in line #2: "language of" should be "language or" agreed > Typo in line #5: "allow give" should choose one. agreed. Delete "allow". > > Delete "as well as an indication of absolute preference" from second > paragraph. Not acceptable. but may be rephrased everywhere to "level of preference across all media" > > Delete "seem to be needed" from end of last sentence of second paragraph. Agreed ( but the beginning of the sentence need adjustments. I take that separately.) > > ---------- > Section 4: I think this is more properly a privacy consideration, so > consider adding a privacy considerations section with this text, and > changing the security considerations to say something such as "no > additional security risks have been identified by the ability to > indicate language." Privacy is usually discussed in the security section. It can be made a subsection. > > > > > Regards Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Apr 7 15:58:43 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5612D580 for ; Thu, 7 Apr 2016 15:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7MCouR2uIDG for ; Thu, 7 Apr 2016 15:58:38 -0700 (PDT) Received: from bin-vsp-out-04.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 7576812D764 for ; Thu, 7 Apr 2016 15:58:37 -0700 (PDT) X-Halon-ID: 3fc24a6c-fd14-11e5-af38-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.7] (unknown [87.96.161.49]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 8 Apr 2016 00:58:31 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: <5706CD04.4060707@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5706E617.8020400@omnitor.se> Date: Fri, 8 Apr 2016 00:58:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5706CD04.4060707@omnitor.se> Content-Type: multipart/alternative; boundary="------------060101040909040506050701" Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:58:41 -0000 This is a multi-part message in MIME format. --------------060101040909040506050701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Bernard, Also the discussion we had in SLIM in October explains the history of the 'lang' attribute. Starting with mail with subject "The use of multiple lang attributes in SDP" on 2015-10-04. Linking it back to a need to describe language negotiation in RFC 2277. This background makes it clear that the intention was for selection and negotiation. /Gunnar Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström: > I had a discussion in mmusic in October 2015 under the subject: > "Clarification for multiple lang attributes in rfc4566bis" > Starting at: > https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis > > /Gunnar > > > > Den 2016-04-07 kl. 22:08, skrev Bernard Aboba: >> Here is what we have in RFC 4566bis >> (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): >> >> Multiple lang attributes can be provided either at session or media >> level if the session or media has capabilities to use multiple >> languages, in which case the order of the attributes indicates the >> order of preference of the various languages in the session or media, >> from most preferred to least preferred. >> >> As a session-level attribute, lang specifies a language capability >> for the session being described. As a media-level attribute, it >> specifies a language capability for that media, overriding any >> session-level language(s) specified. >> The "lang" attribute value must be a single [RFC5646 ] language tag in >> US-ASCII. A "lang" attribute SHOULD be specified when a session is >> of sufficient scope to cross geographic boundaries where the language >> of recipients cannot be assumed, or where the session has >> capabilities in languages different from the locally assumed norm. >> >> Events during the session can influence which language(s) are used, >> and the participants are not strictly bound to only use the declared >> languages. >> >> >> On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba >> > wrote: >> >> In today's meeting, we had folks pointing to discussions of the >> meaning of the "lang" attribute in previous meetings (in >> MMUSIC). Can people post pointers to those previous discussions? >> >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------060101040909040506050701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Bernard,
Also the discussion we had in SLIM in October explains the history of the 'lang' attribute.
Starting with mail with subject "The use of multiple lang attributes in SDP" on 2015-10-04.

Linking it back to a need to describe language negotiation in RFC 2277.

This background makes it clear that the intention was for selection and negotiation.

/Gunnar



Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström:
I had a discussion in mmusic in October 2015 under the subject:
"Clarification for multiple lang attributes in rfc4566bis"
Starting at:
https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis

/Gunnar



Den 2016-04-07 kl. 22:08, skrev Bernard Aboba:
Here is what we have in RFC 4566bis (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): 

   Multiple lang attributes can be provided either at session or media
   level if the session or media has capabilities to use multiple
   languages, in which case the order of the attributes indicates the
   order of preference of the various languages in the session or media,
   from most preferred to least preferred.

   As a session-level attribute, lang specifies a language capability
   for the session being described.  As a media-level attribute, it
   specifies a language capability for that media, overriding any
   session-level language(s) specified.

   The "lang" attribute value must be a single [RFC5646] language tag in
   US-ASCII.  A "lang" attribute SHOULD be specified when a session is
   of sufficient scope to cross geographic boundaries where the language
   of recipients cannot be assumed, or where the session has
   capabilities in languages different from the locally assumed norm.

   Events during the session can influence which language(s) are used,
   and the participants are not strictly bound to only use the declared
   languages.


On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
In today's meeting, we had folks pointing to discussions of the meaning of the "lang" attribute in previous meetings (in MMUSIC).  Can people post pointers to those previous discussions?  



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


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


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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------060101040909040506050701-- From nobody Thu Apr 7 18:47:49 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4012D703 for ; Thu, 7 Apr 2016 18:47:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrR_JXD-pm4i for ; Thu, 7 Apr 2016 18:47:46 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E4F7412D618 for ; Thu, 7 Apr 2016 18:47:45 -0700 (PDT) Received: from dhcp-93ce.meeting.ietf.org (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 7 Apr 2016 18:47:44 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <5706DE97.3030500@omnitor.se> References: <20160407121300.19796.14766.idtracker@ietfa.amsl.com> <5706DE97.3030500@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 7 Apr 2016 18:47:18 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Randall Gellens , Natasha Rooney From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] I-D Action: draft-ietf-slim-use-cases-01.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:47:48 -0000 At 12:26 AM +0200 4/8/16, Gunnar Hellstr=F6m wrote: > Randall, > Sadly very few of your change proposals for the=20 > use case document matches my view of the needs=20 > we have and the requirements they raise. Hi Gunnar, Yes, this is the core of the disagreement. Please see in-line. > > See comments below. > > Den 2016-04-07 kl. 20:29, skrev Randall Gellens: >> >> ---------- >> Use case 2.4, change the text: >> >> Old: >> An answering service will have no guidance to which is >> the preferred modality and may select to use the modality that is >> the callers last resort even if the preferred alternative is >> available. >> >> To: >> An answering service will have no guidance to which is >> the preferred modality and thus all supported modalities >> might be set up. The caller and answerer then use the >> preferred modalities and ignore the non-preferred ones. > Not acceptable. The users need guidance about=20 > how to start the session as humans, not just=20 > which media to enable. > If the answerer starts with the last resort=20 > language/modality but can do the preferred, the=20 > caller may get the wrong impression that the=20 > last resort needs to be used and there will be=20 > a long confusion before they sort out the most=20 > efficient way to communicate. If all media are set up, then the caller can use=20 or not use any of them. (Just as, if during=20 mid-call additional media are enabled, then the=20 caller can start using them.) > > There is also a need to differentiate this case=20 > when just one language/modality is needed from=20 > the cases when both language/modalities are=20 > required. If the caller requests both, and both are=20 established, then a caller who wants both is=20 happy, and a caller who only needed one can=20 ignore the other and also be happy. > > And it is a way for the answering part who=20 > happen to have a terminal only supporting the=20 > caller's last resort that it is ok to answer=20 > with that. The caller would not to announce the=20 > capability if it would mean that it was on same=20 > prerference level as the preferred language=20 > /modality. If it is the caller who knows which media are=20 required, then the caller can use any that were=20 established. If the caller's device knows, then=20 the caller's device could always close the unused=20 media with a re-INVITE and not bother announcing=20 them to the caller. > > Conclusion: Priority declaration across m-lines is required. >> >> The text: >> >> Old: >> In order to not miss any >> calls, the indication of text as last resort would be desirable. >> >> o Solution: need coding of an absolute preference: hi, med, lo >> together with the tag. >> >> Should be deleted. An absolute preference is=20 >> not needed. The worst case outcome is that=20 >> unused media streams are established. > > Not acceptable. see reasoning above. Maybe=20 > absolute preference is not the correct=20 > requirement. Preference level regardless of=20 > m-line is maybe more appropriate description. >> >> ---------- >> In use case 2.5, replace the text: >> >> Old: >> (There is no current solution that says that the >> text path is important. The answering part may see it as an >> alternative.) >> >> o Solution: Need for preference indication per modality >> >> New: >> Both modalities are established, and used as preferred by the humans. >> >> o Solution: Possible >> > Not acceptable. > The text answer path is very strongly preferred. > The voice answer path is just appreciated. > The answering part should not just aswer by=20 > voice phone and ignore the text need. > Coding of a clear preference for getting the text included is needed. The caller asks for both text and voice. If both=20 are established, the caller is happy. Since text=20 is listed first, it is possible that the answerer=20 could in theory (but not likely in practice) only=20 set up text and not voice. The caller's needs=20 are met either way. >> ---------- >> Use case 2.5.1, replace the text: >> >> Old: >> There currently are methods to indicate that the call shall fail if a >> language is not met, but that may be too drastic for some users >> including the one in the above scenario (Section 2.5). It may be >> important to be able to connect and just say something, or use >> residual hearing to get something back when the voice is familiar. >> o Possible solution: coding of an absolute preference together with >> the tag could solve this case if used together with the >> directional indications. For example: >> >> "preference: hi, med, lo" >> >> Another solution would be to indicate required grouping of media, >> however this raises the complexity level. >> >> New: >> There currently are methods to indicate if the call should fail >> or proceed when no languages are in common. In situations such >> as the above scenario (Section 2.5), it may be important to be >> able to connect and just say something, or use residual hearing >> to get something back when the voice is familiar. With emergency >> calls, it is useful for the PSAP call taker to be able to hear >> background and anciliary sounds even if unable to speak to the >> caller. >> >> o Solution: Possible > Yes maybe. This is rather an indication that=20 > the current * parameter is nearly always=20 > needed, and should possibly be the default. >> >> ---------- >> In use case 2.6, change: >> >> OLD: >> direction and find the only possible combination. >> >> o Solution: Need for preference indication per modality >> >> New: >> direction and find possible combinations. >> >> o Solution: Possible > Not acceptable. > It is possible only in the simple case when=20 > only one language in each direction is declared. It works in other cases as well, with the=20 possible downside of establishing unused media=20 streams. > But if the caller want to indicate: > I strongly want to speak, and get text back,=20 > but I can also as the last resort type and get=20 > text back, then it is important to get the=20 > preferred alternative combination on high=20 > priority. Worst case is all media streams are established=20 (audio with some language from caller to=20 answerer, plus text from answerer to caller, plus=20 text two-ways) and the caller speaks using the=20 audio stream and the answerer types using one of=20 the text streams, and the other text stream is=20 not used. What's important is that the call=20 succeeded and the caller and answerer can=20 communicate. >> >> ---------- >> Use cases 2.7, 2.8: >> >> Delete "and absolute level of preference indication" from Solution. > Not acceptable. They are needed. I am not convinced. So far, all use cases will=20 result in a successful call with caller and=20 answerer able to communicate. >> >> ---------- >> Section 3: >> >> Typo in line #2: "language of" should be "language or" > agreed >> Typo in line #5: "allow give" should choose one. > agreed. Delete "allow". Editor's choice which word to use. I don't care. >> >> Delete "as well as an indication of absolute=20 >> preference" from second paragraph. > Not acceptable. but may be rephrased=20 > everywhere to "level of preference across all=20 > media" I do not agree that this phrase is needed either. >> >> Delete "seem to be needed" from end of last sentence of second paragraph= =2E > Agreed ( but the beginning of the sentence=20 > need adjustments. I take that separately.) >> >> ---------- >> Section 4: I think this is more properly a=20 >> privacy consideration, so consider adding a=20 >> privacy considerations section with this text,=20 >> and changing the security considerations to=20 >> say something such as "no additional security=20 >> risks have been identified by the ability to=20 >> indicate language." > Privacy is usually discussed in the security=20 > section. It can be made a subsection. It's become more common to call out privacy in=20 its own section, as a way to highlight privacy=20 issues that are separate from security issues.=20 Sometimes the issues are closely related, in=20 which case discussing them in the security=20 considerations section is the right answer. That=20 doesn't seem to be the case here. >> >> >> >> >> > Regards > > Gunnar > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In Germany they came first for the Communists, and I didn't speak up because I wasn't a Communist. Then they came for the Jews, and I didn't speak up because I wasn't a Jew. They came for the trade unionists, I didn't speak up because I wasn't a trade unionist. Then they came for Catholics, and I didn't speak up because I was a Protestant. Then they came for me, and by that time no one was left to speak up. --Martin Niemoell From nobody Thu Apr 7 23:14:04 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882C212D13A for ; Thu, 7 Apr 2016 23:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vxDgpmSPnWi for ; Thu, 7 Apr 2016 23:14:01 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0106.outbound.protection.outlook.com [104.47.125.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5570B12D0AE for ; Thu, 7 Apr 2016 23:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pVCaytYR3+AgYBC6RDWoyjy3mFe+ibPUMRhokbihS/Q=; b=StPS7KhCukrV1Zw0NMjI925QXJ/NouPTXY/YEWJsuXimXbzsH3vwP19BK61d+icNP30ZraFldyWjJW8ggfg0egDRftJdPiQu8ZZW24FD9nC+9LDZYPSmoDf/JNmu3VT/YrcA3axPzX5UUnM8ihA7O5yTNTFrABrUbhkKo3EA2Iw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0915.jpnprd01.prod.outlook.com (10.167.178.21) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 8 Apr 2016 06:13:57 +0000 To: Randall Gellens , Bernard Aboba , References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <57074C26.4060605@it.aoyama.ac.jp> Date: Fri, 8 Apr 2016 15:13:58 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0016.apcprd06.prod.outlook.com (10.164.91.26) To OS2PR01MB0915.jpnprd01.prod.outlook.com (10.167.178.21) X-MS-Office365-Filtering-Correlation-Id: 185d35c1-505e-43cf-7278-08d35f74f81c X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 2:4NqCEcpo78gVr9vfB7e5EvnEYl8yfu06wPBkY1AeREjYvyT+hModn69Nd30nlCE2BZP3DMSshln/Zsaa7Ku/U1wAqjCKRgo8wIFada7MDlxUSJVpZ17d87FnCYRZAJ3E/7/CO0Q3W11amqCfJQeIa6XCtWew5TGqMgcYHDNFT6RWb4e4qYSf+Cm5qE55+4qP; 3:mcp+QtUifdOcvLu8SD7vrGe9tkkjw0AVOFZs14knxpWTfP2ZbaDq3P0be7NDWzXlhc+aoxpO2/uGzrMC2f1kfmJetg7LyHj7Xn5wNeeYVsnv1IV+9RvSjUz38csqa+wd; 25:UXtYvvyzFJTK4dk/BMDhmE7xHsWjmsYtjvK+UP9b2TkLGmwC3+W+n/a8FUtvYbXzTHcWJq/98teJesMA96S6AHSccCTwKmjNIG9nWGgV+NAM62bfbzcrcgVosVKfpD1TLKk7CjEDBDejeUABd270qZU5frLdJ2Hzd7m421NHvn7WtJ9apbE4mkrDBrDqOLrypWJ+k6St2ltGxjcki8+cUyW6dIToA12RgXOIcbScG/EXMqX5dHoP0nNilEs5kEUV3DtG6QTE32AvFP16o3vHROwVu8Q6zFp5FGlzFxmdUUU2iWSUbeXLV85wOJLApOpveRM5yRizwQ+oGZuuRqYiXQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0915; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040074)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046)(6042046); SRVR:OS2PR01MB0915; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0915; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 4:b8okeTjKI76E1fATMygHtFXibvpDUbW7R+G3Qyd7nZEY2j0OPtPrqMkMYhxRYXL8xZypNzofyv3qFJstNqeb2WVNAk7LvQAc+DoeQRQpPvPJEfAEY/6+IU3E2S7nIVc2VqL3fJGqz7Im7EU/dcjxQ2BoyYB/ZC2QhpkIPzSNcRufdKVptxfz/FCElGMvBUqd1GGj805MNsGbn9Ohcsj3fvIHMb4UvV1otWWt1SXMznPZBLBYRTc4sw2M3dYJ9nLFzLbLJ7IkFrkssBmMitZzw9jkseCyFn5qbDM6BlqASja0fV47H75oI6AvEjYF1+Wox3TZPFj4mw/iiGM5vtr/aGo9OTrvbnQbb7F6coSVzya0oyyYfVJ7gI8T+wUJHd6l5oNQ1ZKP+mvKvs9bKQn5V3xQtwl58HGVz/JDfudyy1UYzQZlXc7NXavtBTVwNP3V X-Forefront-PRVS: 0906E83A25 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(86362001)(92566002)(50466002)(189998001)(23676002)(83506001)(33656002)(1096002)(64126003)(80316001)(5004730100002)(5008740100001)(81166005)(59896002)(65806001)(65956001)(230700001)(107886002)(2950100001)(66066001)(5001770100001)(87266999)(2906002)(54356999)(65816999)(99136001)(77096005)(76176999)(47776003)(74482002)(6116002)(586003)(50986999)(3846002)(42186005)(4001350100001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0915; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwOTE1OzIzOnlPemJUZlQrWjlkRFQwM0Y4MmVYbnAzaUJR?= =?utf-8?B?dEduT2J3TklhTkd6TWd5NHh0VWd3OVJQaFMzcXg5M1Jad0hlVVIvWVJwZlB1?= =?utf-8?B?Skk0ZXNmVjc5SDZ4MDZQY3FTSVlQVXZkbXhwRGVvbU9XKzNqQnQ4Z2ZLQmNi?= =?utf-8?B?cUdWbW9RakVKSVNkN3g3SWJ2UU9TY1ZwSktWV0RFai80RDRwQ2hoQUxybWUw?= =?utf-8?B?VlkwT0JBS2xjTTZtSEwzWnh3Zkd2Zm14YklXK2NvK0pkRDI4bjU5MVh5UUly?= =?utf-8?B?Z05uRjhCVGxaOHZvY05Xc1QzWFB0N0VoekhZc0czNkUyVUZBTS9vbEVsdXBU?= =?utf-8?B?azlaTGx3YXp3N0V4a2hoVTFFN1B5eGZVeC9uWWVaMzlxOFlieDNGV0RBcDBo?= =?utf-8?B?STh3SUsxZDhHZ010dmQ4Y0VLTjVpeDFqU2pOak1hWXMydVk2eHdCQnFYblJs?= =?utf-8?B?bk1HNnVnZ3pBTnAvVnFUbkZORmx6aTBrRDN6R1pWMzZsUFcyVk9BSFN5cGlk?= =?utf-8?B?WHZnckk5ZkRSR0hqLzJpMndDekRlTmhpS0RxYU1CZHFucmxRdmVPT0lqL1Zi?= =?utf-8?B?V01zUFR0NWpmbythU0wzRnN1Z1ArSENsWjRKK2NiTTlGd1BoSkJvNVhVVGJL?= =?utf-8?B?Mm1YUEhrVzhTRms1VVhQNGJEbVhqTGJjTHlQbWJleGpJdHlKK2dOVzJZb21S?= =?utf-8?B?Q2xqMXVZVHBRbExiR0pvRkpnN1NheTN4WTd3OHpXUGh2b3VwQUJzaGNJR0RD?= =?utf-8?B?Sml1MzJIU09sVW5KZE8xdVpLempDcWNPQmdqVldqcSt2SFBPOENVVGppZnR3?= =?utf-8?B?S0xQQnZJOHB1TTlVMGNqRWpJY3MwdDRyNzFMNC82bXloZGo3SGhuMThBSWpH?= =?utf-8?B?dzFWZ1hRY2Vlc3N0SlRLY0ptdXBvTUZTalF6RVF3OVovZTAzck53QU1FU2RE?= =?utf-8?B?RUtZVGZZWmp2bDJyVGJlWng5Mk02WGY3TlU4MGpaSHl0STRkYlJWcEtWVlN5?= =?utf-8?B?ZkllY0lIU2hwNzFOQnROUDByL0txalh2Z214cnVldEIyZkZlYkVMNHQrazNU?= =?utf-8?B?dlRFZ0N0Ti9oM1dtRDdpb3grOFBEQm9LY2dCRUxhaWgwZDJqYms2Q0JGVkdL?= =?utf-8?B?VmNuZmR0YS9sNDR2UDlwekVjUjVLblNJSEZhRVU2eHhBdFNJZElWSXJxV2Yv?= =?utf-8?B?TGJLcUZBQUwzNlpwSzdlT3VwUDIwYndiam10cUVGQ0t1UVZnM3RpMjlrQktU?= =?utf-8?B?WW9MY2ZnNU5od1kzN1MyaVREVHowRExUMjlNSHNQVTRGNW5WT1BaZitJS1VW?= =?utf-8?B?TVhDT0JuOHZsRTVkSDRSaFNmY3Bud0VESlFURDJXajZOQjVjdkQ4R09XMjdn?= =?utf-8?B?NFlMN0lGMTlZUmZoSU90T2ZnSUxnaDBvQ09xUTFwY2hZaTFxRnREOWR3TUNz?= =?utf-8?B?SlhKR1g2OGY2K1NxdVZHc0lqRUpLL1VLSzE0OXlJaXNYWE84dVFpZjRpZGRB?= =?utf-8?B?cWlndz09?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 5:ThmSCFZCb+ZE14OJlqS+mjBqqn7hyLwx/igpW/Xk0eUR9Vffth0BRA6k2B8rqE0wZZ5A2v/map5mAbcoUZqIAvqYp6B1S825VVc777VVDoWiAr63IhhassdAm9A0GzekhDMk5gQbXXHjvKFcZcSbcQ==; 24:vjRMKXy5DMg9NdDihbB3CbjaVH6OufWDUmRZiWDa/5YJZMnB6r/gpL6VCZgCCgH3TKQkbTvRgxmvEtSSVQl/Cv81gsBg2pCL36awSH7I4Us= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2016 06:13:57.1580 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0915 Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 06:14:03 -0000 I wasn't there, so I can't speak from experience, but On 2016/04/08 06:40, Randall Gellens wrote: > There were various ad-hoc discussions going back a number of years. I'd > have to do a search of my email archives to find them all, but I do have > notes from a meeting in 2013 where some combination of the following > people attended (all of whom indicated interest in participating; I sent > notes from the discussion to all of them, but didn't note who was > there): > Peter Saint-Andre, > Flemming Andreasen, Gunnar Hellstrom, > Brian Rosen, > Keith Drage, > Peter Saint-Andre, > Brian Rosen, some people paid for doubles, or there were too many mirrors in the room, or some people already had a bit too much booze, or whatever. Regards, Martin. > Hannes Tschofenig, > Ari Keranen, Alexey Melnikov, John C Klensin, Harald Alvestrand, Andrew > Hutton, Pete Resnick, Dale Worley, Randall Gellens. The notes indicate > that we agreed that: > > New SDP attribute(s) vs re-use of existing 'lang' attribute: > - Existing attribute semantics are unclear so should be avoided > - Minting new attributes is cheap > From nobody Fri Apr 8 01:34:27 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C71712D0B3 for ; Fri, 8 Apr 2016 01:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me3lkmV7dp63 for ; Fri, 8 Apr 2016 01:34:22 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2411E12D114 for ; Fri, 8 Apr 2016 01:34:21 -0700 (PDT) X-Halon-ID: af4c99f3-fd64-11e5-88ba-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.58] (unknown [87.96.161.49]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Fri, 8 Apr 2016 10:34:18 +0200 (CEST) To: "slim@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <57076D07.8000300@omnitor.se> Date: Fri, 8 Apr 2016 10:34:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:34:25 -0000 There is a wording in draft-ietf-slim-negotiating-human-language-01.txt that needs slight adjustment, and also can shed some light on the discussed wording around 'lang' in RFC 4566. I made a comment on this in a mail about change proposals yesterday but bring it up here for discussion. It is this section in 6.2 " There are two attributes, one ending in "-send" and the other in "-recv" to indicate the language used when sending and receiving media: a=humintlang-send: a=humintlang-recv: Each can appear multiple times in an offer for a media stream. In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send using the media, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive using the media. " The wish to use simple language has caused some uncertainty that requires studying of the language in the whole section to find out the real meaning. It is likely that the same kind of desire to use simple wording caused the wording around the 'lang' attribute in RFC4566 to be possible to interpret in different ways. 1. On line 2 it says "to indicate the language used" when it in some cases can be a list, of which at least one in each direction will be used. I suggest to change to "each indicating a language possible to use" 2. The expression later: "the languages the offerer wishes to send" reads as if the offeror has a preference to send in multiple languages, while we really mean an offered selection. Change from: "In an offer, the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the offerer wishes to send using the media, and the 'humintlang-recv' values constitute a list in preference order of the languages the offerer wishes to receive using the media." To: "In an offer the 'humintlang-send' values constitute a list in preference order (first is most preferred) of the languages the party is capable to select from for sending using the media, and the 'humintlang-recv' values constitute a list in preference order of the languages in which the party is capable of receiving contents using the media." Note that in the change proposal from yesterday, I also include the answering part in the description and move the preference description to a separate paragraph in order to describe the preference to have scope across all media lines. That is still the valid proposal, so see the above as a proposal just for the topic of inclusive list versus selection. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Fri Apr 8 05:24:53 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3838012D7E7 for ; Fri, 8 Apr 2016 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivTFj1uRCB7X for ; Fri, 8 Apr 2016 05:24:49 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 7455112D7E9 for ; Fri, 8 Apr 2016 05:24:49 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f52so88544385qga.3 for ; Fri, 08 Apr 2016 05:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SKpFNEfyVvQZARa0+KtcB6LWdeaZPtdUpK3Eu6ySWr4=; b=grTqY26H03sgirimbKm5xg2z6EuyGo1litRaPqFugwByOdZHiPpjndOZ9awhjciXwS k8XQrTtLm3XLXA5L7upFgbOxGd4TlFFFTFwy3LSIpNmtpVPsHdEGMnbVBUy0+xLpGDxq GvsynCMVVf7ULQOdsNf9qOZccpJKVxHXNEbYhKr4dzBqNd+Tygj4qyh4aFeqIP/8k5iw CXGJgCwxTDzH5u8PgZeyYUaIRcHE5T35Co+670KC+U7S+CnofNZ6UNy3VoN35zmhYfuM HmgZBOtYwglHt2xXKVOpbx5lJ39r5oXMtjXCZWFom9KNLVlKpO6RnhP6i9GfCYe2DhhA hOnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SKpFNEfyVvQZARa0+KtcB6LWdeaZPtdUpK3Eu6ySWr4=; b=Ml3anZpLM16lj5cJz+pXLXANgr1WGoKx8lI3RN+wwGZ6DEk9rKzt/xQ4bmRnuKG4NR 86MJrdv5ZO5pqv3VRzwKpN3gcZA7V/cD6Mo3aC5mtq4MkgsjvYIFecBE/uqn6TZhM/ck Uy7htRGbED4CwnPEJJqrIJEl/sImt+MUyRTI5F02P4sGiIRjAmeuds3bA/waFHvSOkyw gMDXV8DwMi/nvm42NH+0b+UONiIMHHhj0AHb+/S5nwFFQh7Xznq4PIaBE8D+J/vL6y5s pDOikAA8EzPLqXaF8zpx6hcnLGn7bCNU1sHvWf9AIVSwIehOGGnRd+CQMQpG5D31OuFm xPeg== X-Gm-Message-State: AD7BkJLfpLRuvLkXcj4XezrWJMiXhfcnLNiMr7qti9CYhSGTMpFwRS+x05ld/NC1yEt9Gg== X-Received: by 10.140.89.19 with SMTP id u19mr10690988qgd.90.1460118288597; Fri, 08 Apr 2016 05:24:48 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:35ce:1300:c4ff:6d8b? ([2001:67c:370:176:35ce:1300:c4ff:6d8b]) by smtp.gmail.com with ESMTPSA id s8sm5355053qhb.20.2016.04.08.05.24.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 05:24:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <57074C26.4060605@it.aoyama.ac.jp> Date: Fri, 8 Apr 2016 09:24:46 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3F73544F-2956-43DC-BB1D-7DEDE527AA17@brianrosen.net> References: <57074C26.4060605@it.aoyama.ac.jp> To: =?utf-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: slim@ietf.org, Randall Gellens , Bernard Aboba Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:24:52 -0000 Yes, of course. I had a double! I was there, twice! > On Apr 8, 2016, at 3:13 AM, Martin J. D=C3=BCrst = wrote: >=20 > I wasn't there, so I can't speak from experience, but >=20 > On 2016/04/08 06:40, Randall Gellens wrote: >=20 >> There were various ad-hoc discussions going back a number of years. = I'd >> have to do a search of my email archives to find them all, but I do = have >> notes from a meeting in 2013 where some combination of the following >> people attended (all of whom indicated interest in participating; I = sent >> notes from the discussion to all of them, but didn't note who was >> there): >=20 >> Peter Saint-Andre, >=20 >> Flemming Andreasen, Gunnar Hellstrom, > > Brian Rosen, >=20 >> Keith Drage, >=20 >> Peter Saint-Andre, >> Brian Rosen, >=20 > some people paid for doubles, or there were too many mirrors in the = room, or some people already had a bit too much booze, or whatever. >=20 > Regards, Martin. >=20 >> Hannes Tschofenig, >> Ari Keranen, Alexey Melnikov, John C Klensin, Harald Alvestrand, = Andrew >> Hutton, Pete Resnick, Dale Worley, Randall Gellens. The notes = indicate >> that we agreed that: >>=20 >> New SDP attribute(s) vs re-use of existing 'lang' attribute: >> - Existing attribute semantics are unclear so should be = avoided >> - Minting new attributes is cheap >>=20 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Fri Apr 8 05:39:47 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8B712D682 for ; Fri, 8 Apr 2016 05:39:40 -0700 (PDT) X-Quarantine-ID: <2waQxnvv3wHL> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2waQxnvv3wHL for ; Fri, 8 Apr 2016 05:39:38 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A866B12D8DC for ; Fri, 8 Apr 2016 05:39:18 -0700 (PDT) Received: from dhcp-93ce.meeting.ietf.org (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 8 Apr 2016 05:39:17 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <57074C26.4060605@it.aoyama.ac.jp> References: <57074C26.4060605@it.aoyama.ac.jp> X-Mailer: Eudora for Mac OS X Date: Fri, 8 Apr 2016 05:38:16 -0700 To: Martin J. =?iso-8859-1?Q?D=FCrst?= , Bernard Aboba , From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:39:41 -0000 At 3:13 PM +0900 4/8/16, Martin J. D=FCrst wrote: > some people paid for doubles, or there were too=20 > many mirrors in the room, or some people=20 > already had a bit too much booze, or whatever. Sorry, I coped the names from the email=20 recipients and neglected to do a duplicate=20 removal operation (left as an exercise for the=20 reader). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Look Bruce, the bat signal!!! From nobody Fri Apr 8 05:59:08 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C2112D6F4 for ; Fri, 8 Apr 2016 05:59:07 -0700 (PDT) X-Quarantine-ID: <9aH3Rj5Pw-me> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aH3Rj5Pw-me for ; Fri, 8 Apr 2016 05:59:06 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0B78512D56A for ; Fri, 8 Apr 2016 05:52:34 -0700 (PDT) Received: from dhcp-93ce.meeting.ietf.org (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 8 Apr 2016 05:52:33 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <57076D07.8000300@omnitor.se> References: <57076D07.8000300@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Fri, 8 Apr 2016 05:52:29 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , "slim@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:59:08 -0000 Hi Gunnar, At 10:34 AM +0200 4/8/16, Gunnar Hellstr=F6m wrote: > 1. On line 2 it says "to indicate the language=20 > used" when it in some cases can be a list, of=20 > which at least one in each direction will be=20 > used. > > I suggest to change to "each indicating a language possible to use" Thanks for pointing this out. I think the best=20 way to fix the possible ambiguity here is to=20 simply delete the text "to indicate the language=20 used when sending and receiving media", because=20 further down it is explained in more detail. > > 2. The expression later: "the languages the=20 > offerer wishes to send" reads as if the offeror=20 > has a preference to send in multiple languages,=20 > while we really mean an offered selection. > > Change from: > "In an offer, the 'humintlang-send' values constitute a list in > preference order (first is most preferred) of the languages the > offerer wishes to send using the media, and the 'humintlang-recv' > values constitute a list in preference order of the languages the > offerer wishes to receive using the media." > > To: > "In an offer the 'humintlang-send' values=20 > constitute a list in preference order (first is=20 > most preferred) of the languages the party is=20 > capable to select from for sending using the=20 > media, and the 'humintlang-recv' values=20 > constitute a list in preference order of the=20 > languages in which the party is capable of=20 > receiving contents using the media." I think a more clear and direct way of phrasing it is: In an offer, 'humintlang-send' indicates the language the offerer wishes to send using the media, and 'humintlang-recv' indicates the language the offerer wishes to receive using the media. In both cases the values constitute a list of languages in preference order (first is most preferred). > > Note that in the change proposal from=20 > yesterday, I also include the answering part in=20 > the description and move the preference=20 > description to a separate paragraph in order to=20 > describe the preference to have scope across=20 > all media lines. That is still the valid=20 > proposal, so see the above as a proposal just=20 > for the topic of inclusive list versus=20 > selection. > > Gunnar > > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- MIPS: Meaningless Indicator of Processor Speed. From nobody Fri Apr 8 08:11:45 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6912D942 for ; Fri, 8 Apr 2016 08:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtW7Xcy7JOcL for ; Fri, 8 Apr 2016 08:11:41 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCB512D548 for ; Fri, 8 Apr 2016 08:11:41 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by comcast with SMTP id oY3WaXrvdO4QFoY4Sayd2R; Fri, 08 Apr 2016 15:11:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460128300; bh=wWdOxkKOo6m8ryjcD9Lnojm2ZlArGTtgHfSj1iMNBw0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fXy5yMtAZp2kT/qfDYJWg2kRVXvxbGxSqGZVlS3u6poQnbUEDK7DwajxecVTFN0VA QQGs3rAwCleAwf7SXjYDz+NwjUoLi6e9zJvgl4dHZuFu9HLrVqQxzjNQxeyPh7/VCA w14Pi7+Af+Ykc+1kl0eB2iOjBhEE7oov1Gz4myZpGY9sDkP8XkxCGfKksX3PiBMIOl So6G8LlhwJ7xezUAknpokynUO1qyvY+9k+JHIRPRKGDHD5WE8L8ikFtk5D/XylogEE P07uvq85Ym8JKlFIuijk+XMy/LtaeDJyEkms1VOGPxJse4SXwMY/li2BYE7l43hVLe kQW5fWSDEj3yg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with comcast id frBf1s00V3KdFy101rBg51; Fri, 08 Apr 2016 15:11:40 +0000 To: slim@ietf.org References: From: Paul Kyzivat Message-ID: <5707CA2A.9050808@alum.mit.edu> Date: Fri, 8 Apr 2016 11:11:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Slim] Volunteers for direct multipart/multilingual email tests X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:11:42 -0000 I'm happy to volunteer. However I suffer from not being multilingual, so I'm limited in the tests I can do. Thanks, Paul On 4/7/16 4:53 PM, Nik Tomkinson wrote: > Hi all, > > as I mentioned in the session today, I would like to do some wider > testing of the suggested structure for multipart/multilingual email (eg, > with message/rfc822 and message/global as inner parts). > > Please can you let me know if you want to help out with this and, if so, > please let me know the email address for me to use. All I am after is an > idea of how well your email clients handle the format and if there are > any issues that could be addressed. > > The multilingual mail is likely to come from a different address to this > one which is a restriction of the script I am using to send a hand-coded > message. > > I will start sending some test emails in the next few days and I will > try to send one to this group as well. > > Nik. > > -- > > ----------------------------------------------------------------- > Multiple Language Content Type Internet Draft: > > https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ > > > ----------------------------------------------------------------- > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > From nobody Sun Apr 10 12:45:10 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74FA12D0F2 for ; Sun, 10 Apr 2016 12:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sS_nj1_0FsFX for ; Sun, 10 Apr 2016 12:45:05 -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 4E3CC12D5C3 for ; Sun, 10 Apr 2016 12:45:04 -0700 (PDT) X-Halon-ID: afa82529-ff54-11e5-aff2-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.92] (unknown [87.96.161.49]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 10 Apr 2016 21:44:49 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: <5706CD04.4060707@omnitor.se> <5706E617.8020400@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <570AAD38.1090705@omnitor.se> Date: Sun, 10 Apr 2016 21:44:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5706E617.8020400@omnitor.se> Content-Type: multipart/alternative; boundary="------------050202000106070706020004" Archived-At: Subject: Re: [Slim] Claim of consensus on meaning of RFC 4566 "lang" attribute X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 19:45:08 -0000 This is a multi-part message in MIME format. --------------050202000106070706020004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The very origin of the 'lang' sdp attribute is its announcement last in this e-mail from 1997-11-23 https://mailarchive.ietf.org/arch/msg/mmusic/hEU4yCmc31ib4Vk23aCQPfm5QvQ It is said to fulfill a requirement from a draft that later became RFC 2277. /Gunnar Den 2016-04-08 kl. 00:58, skrev Gunnar Hellström: > Bernard, > Also the discussion we had in SLIM in October explains the history of > the 'lang' attribute. > Starting with mail with subject "The use of multiple lang attributes > in SDP" on 2015-10-04. > > Linking it back to a need to describe language negotiation in RFC 2277. > > This background makes it clear that the intention was for selection > and negotiation. > > /Gunnar > > > > Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström: >> I had a discussion in mmusic in October 2015 under the subject: >> "Clarification for multiple lang attributes in rfc4566bis" >> Starting at: >> https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis >> >> /Gunnar >> >> >> >> Den 2016-04-07 kl. 22:08, skrev Bernard Aboba: >>> Here is what we have in RFC 4566bis >>> (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): >>> >>> Multiple lang attributes can be provided either at session or media >>> level if the session or media has capabilities to use multiple >>> languages, in which case the order of the attributes indicates the >>> order of preference of the various languages in the session or media, >>> from most preferred to least preferred. >>> >>> As a session-level attribute, lang specifies a language capability >>> for the session being described. As a media-level attribute, it >>> specifies a language capability for that media, overriding any >>> session-level language(s) specified. >>> The "lang" attribute value must be a single [RFC5646 ] language tag in >>> US-ASCII. A "lang" attribute SHOULD be specified when a session is >>> of sufficient scope to cross geographic boundaries where the language >>> of recipients cannot be assumed, or where the session has >>> capabilities in languages different from the locally assumed norm. >>> >>> Events during the session can influence which language(s) are used, >>> and the participants are not strictly bound to only use the declared >>> languages. >>> >>> >>> On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba >>> > wrote: >>> >>> In today's meeting, we had folks pointing to discussions of the >>> meaning of the "lang" attribute in previous meetings (in >>> MMUSIC). Can people post pointers to those previous discussions? >>> >>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------050202000106070706020004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit The very origin of the 'lang' sdp attribute is its announcement last in this e-mail from 1997-11-23
https://mailarchive.ietf.org/arch/msg/mmusic/hEU4yCmc31ib4Vk23aCQPfm5QvQ

It is said to fulfill a requirement from a draft that later became RFC 2277.

/Gunnar



 

Den 2016-04-08 kl. 00:58, skrev Gunnar Hellström:
Bernard,
Also the discussion we had in SLIM in October explains the history of the 'lang' attribute.
Starting with mail with subject "The use of multiple lang attributes in SDP" on 2015-10-04.

Linking it back to a need to describe language negotiation in RFC 2277.

This background makes it clear that the intention was for selection and negotiation.

/Gunnar



Den 2016-04-07 kl. 23:11, skrev Gunnar Hellström:
I had a discussion in mmusic in October 2015 under the subject:
"Clarification for multiple lang attributes in rfc4566bis"
Starting at:
https://mailarchive.ietf.org/arch/search/?email_list=mmusic&qdr=y&q=rfc4566bis

/Gunnar



Den 2016-04-07 kl. 22:08, skrev Bernard Aboba:
Here is what we have in RFC 4566bis (https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-16#page-36): 

   Multiple lang attributes can be provided either at session or media
   level if the session or media has capabilities to use multiple
   languages, in which case the order of the attributes indicates the
   order of preference of the various languages in the session or media,
   from most preferred to least preferred.

   As a session-level attribute, lang specifies a language capability
   for the session being described.  As a media-level attribute, it
   specifies a language capability for that media, overriding any
   session-level language(s) specified.

   The "lang" attribute value must be a single [RFC5646] language tag in
   US-ASCII.  A "lang" attribute SHOULD be specified when a session is
   of sufficient scope to cross geographic boundaries where the language
   of recipients cannot be assumed, or where the session has
   capabilities in languages different from the locally assumed norm.

   Events during the session can influence which language(s) are used,
   and the participants are not strictly bound to only use the declared
   languages.


On Thu, Apr 7, 2016 at 1:03 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
In today's meeting, we had folks pointing to discussions of the meaning of the "lang" attribute in previous meetings (in MMUSIC).  Can people post pointers to those previous discussions?  



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


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


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


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


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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------050202000106070706020004-- From nobody Sun Apr 10 13:49:06 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6D12D124 for ; Sun, 10 Apr 2016 13:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZwmiVBCOkou for ; Sun, 10 Apr 2016 13:49:02 -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 CBDED12D0F0 for ; Sun, 10 Apr 2016 13:49:01 -0700 (PDT) X-Halon-ID: a1dd0766-ff5d-11e5-8ffb-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.92] (unknown [87.96.161.49]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sun, 10 Apr 2016 22:48:51 +0200 (CEST) To: Randall Gellens , "slim@ietf.org" References: <57076D07.8000300@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <570ABC35.5000808@omnitor.se> Date: Sun, 10 Apr 2016 22:48:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Slim] Wording about selection in draft-ietf-slim-negotiating-human-language-01 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 20:49:05 -0000 Randall, See comments below Den 2016-04-08 kl. 14:52, skrev Randall Gellens: > Hi Gunnar, > > At 10:34 AM +0200 4/8/16, Gunnar Hellström wrote: > >> 1. On line 2 it says "to indicate the language used" when it in some >> cases can be a list, of which at least one in each direction will be >> used. >> >> I suggest to change to "each indicating a language possible to use" > > Thanks for pointing this out. I think the best way to fix the > possible ambiguity here is to simply delete the text "to indicate the > language used when sending and receiving media", because further down > it is explained in more detail. Possibly. Please show the section with your proposed modification so that it can be assessed. > >> >> 2. The expression later: "the languages the offerer wishes to send" >> reads as if the offeror has a preference to send in multiple >> languages, while we really mean an offered selection. >> >> Change from: >> "In an offer, the 'humintlang-send' values constitute a list in >> preference order (first is most preferred) of the languages the >> offerer wishes to send using the media, and the 'humintlang-recv' >> values constitute a list in preference order of the languages the >> offerer wishes to receive using the media." >> >> To: >> "In an offer the 'humintlang-send' values constitute a list in >> preference order (first is most preferred) of the languages the party >> is capable to select from for sending using the media, and the >> 'humintlang-recv' values constitute a list in preference order of the >> languages in which the party is capable of receiving contents using >> the media." > > I think a more clear and direct way of phrasing it is: > > In an offer, 'humintlang-send' indicates the language the offerer > wishes to send using the media, and 'humintlang-recv' indicates the > language the offerer wishes to receive using the media. In both > cases the values constitute a list of languages in preference order > (first is most preferred). No, this is as unclear as the initial wording. It says that the attribute indicates a language, when it can indicate a list of languages. It is safer to describe it exactly as in my proposal above. I also think that the se of the word "wish" complicates it. If you say that the list is a list of languages the user wishes to use, then you get the impression that more would be better. If you instead say that the user is capable of using, then it is neutral and selecting one is sufficient. > > >> >> Note that in the change proposal from yesterday, I also include the >> answering part in the description and move the preference description >> to a separate paragraph in order to describe the preference to have >> scope across all media lines. That is still the valid proposal, so >> see the above as a proposal just for the topic of inclusive list >> versus selection. Still true. /Gunnar >> >> Gunnar >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sun Apr 10 15:41:56 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119B12D0D9 for ; Sun, 10 Apr 2016 15:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdTR937-J8v5 for ; Sun, 10 Apr 2016 15:41:53 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 C23DF12D0AC for ; Sun, 10 Apr 2016 15:41:52 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f105so107409525qge.2 for ; Sun, 10 Apr 2016 15:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RVhyD2QQ8n+PDFmPdVM1AtO1q0QH6R2y/CTTDD0diW0=; b=0rXPo8gyxyHlCfLcQaQiz6uZZTKSvfKPp/OXN0qUnFfpDUOtQ3bAfGN8lzKgOpmiSF iIEShSKKjGT3kFw+y3GOAnBehhZBDO7K7igqZLTRr5NKNebfK1cFNbQbrnBJdcblQUGL IX9nRanHuAVRn2qnfERcaLIhXzHmoXPfP9I3TMSifcv38igK44tpsHy4nKYUBjUGd848 rTcksVyoE6qc9/Qsj6qqfrOiKTmA6qRpTut6O3Hkx8lx1Ihg6RZZxLg1wYTenXLZpF1q S9s+VfIbn6VPr+VX+N8fBjyhq7DdREKmIpYAmJu1RCJW3tLPjPlNL//QyOYiffQLhIjs xpaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RVhyD2QQ8n+PDFmPdVM1AtO1q0QH6R2y/CTTDD0diW0=; b=DVdMmghCvufGQl6ehvijEDgOo3y3bvk7m6mMdDkfRf3LgLFCLvalb+KmgMg7IYvg46 ffL9mlL/7rXLlybUoTFuSuWYyhXd6gHpm0WSpIRPKdSykbsqIvI0zutbPLtvqp7sQ2hf w+wwTXcOa4EcpKeRbXoGWE9exZZ5pHuWsxhO2WM009suwKv+8GX/M+M33/13S8M+UrpN /ZNEJj5NxyjyUWm/nX3TPk8IFlhDKmdAoIhnoelQ47p63tfmvUwiC1Lcx1Cu6ZF4Ky26 bX85jdeynpZ+faHMkqNBry+hVVlzjrCNik7JWGBQ9kp5BFXVSMDFZ+dbhDM/PkC7ZjcN Cm7A== X-Gm-Message-State: AD7BkJKW8zFM6SoUR3fXiov1uOAIx956K1bSh8L0SeCWFkbbwE4D1eQxEWsyU8LKXFetEHRyXOuha2QFpzb8Gg== MIME-Version: 1.0 X-Received: by 10.140.100.184 with SMTP id s53mr24253912qge.19.1460328111911; Sun, 10 Apr 2016 15:41:51 -0700 (PDT) Received: by 10.55.8.148 with HTTP; Sun, 10 Apr 2016 15:41:51 -0700 (PDT) In-Reply-To: <5707CA2A.9050808@alum.mit.edu> References: <5707CA2A.9050808@alum.mit.edu> Date: Sun, 10 Apr 2016 23:41:51 +0100 Message-ID: From: Nik Tomkinson To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1134f2085dbb94053029224b Archived-At: Cc: slim@ietf.org Subject: Re: [Slim] Volunteers for direct multipart/multilingual email tests X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 22:41:55 -0000 --001a1134f2085dbb94053029224b Content-Type: text/plain; charset=UTF-8 Hi All, I have sent the first test which was a simple multipart/multilingual with message/rfc822 inner parts and no language-independant part to: br@brianrosen.net brian.rosen@gmail.com brian.rosen@neustar.biz nrooney@gsma.com gunnar.hellstrom@omnitor.se gunnarhm@gmail.com duerst@it.aoyama.ac.jp pkyzivat@alum.mit.edu nsb@mimecast.com rfc.nik.tomkinson@gmail.com Thanks for your help. I'll wait for some replies and then try the message/rfc822 with a language-independant part in the next few days and a message/global version soon after that. Nik. On 8 April 2016 at 16:11, Paul Kyzivat wrote: > I'm happy to volunteer. However I suffer from not being multilingual, so > I'm limited in the tests I can do. > > Thanks, > Paul > > On 4/7/16 4:53 PM, Nik Tomkinson wrote: > >> Hi all, >> >> as I mentioned in the session today, I would like to do some wider >> testing of the suggested structure for multipart/multilingual email (eg, >> with message/rfc822 and message/global as inner parts). >> >> Please can you let me know if you want to help out with this and, if so, >> please let me know the email address for me to use. All I am after is an >> idea of how well your email clients handle the format and if there are >> any issues that could be addressed. >> >> The multilingual mail is likely to come from a different address to this >> one which is a restriction of the script I am using to send a hand-coded >> message. >> >> I will start sending some test emails in the next few days and I will >> try to send one to this group as well. >> >> Nik. >> >> -- >> >> ----------------------------------------------------------------- >> Multiple Language Content Type Internet Draft: >> >> >> https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ >> >> >> ----------------------------------------------------------------- >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> >> > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/ ----------------------------------------------------------------- --001a1134f2085dbb94053029224b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I have sent the first test whic= h was a simple multipart/multilingual with message/rfc822 inner parts and n= o language-independant part to:


Thanks for your help. I'll wait for som= e replies and then try the message/rfc822 with a language-independant part = in the next few days and a message/global version soon after that.

Nik.

On 8 April 2016 at 16:11, Paul Kyzivat &= lt;pkyzivat@alum= .mit.edu> wrote:
I'm = happy to volunteer. However I suffer from not being multilingual, so I'= m limited in the tests I can do.

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

On 4/7/16 4:53 PM, Nik Tomkinson wrote:
Hi all,

as I mentioned in the session today, I would like to do some wider
testing of the suggested structure for multipart/multilingual email (eg, with message/rfc822 and message/global as inner parts).

Please can you let me know if you want to help out with this and, if so, please let me know the email address for me to use. All I am after is an idea of how well your email clients handle the format and if there are
any issues that could be addressed.

The multilingual mail is likely to come from a different address to this one which is a restriction of the script I am using to send a hand-coded message.

I will start sending some test emails in the next few days and I will
try to send one to this group as well.

Nik.

--

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

 <http://datatracker.ietf.org/doc= /draft-tomkinson-multilangcontent/>https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/<= /a>
<http://datatracker.ietf.or= g/doc/draft-tomkinson-slim-multilangcontent/>

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



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


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



--
=
= 
--------------------------------------------------------=
---------
Multiple Language Content Type Internet Draft:
= https://datatracker.ietf.org/doc/draft-ietf-s= lim-multilangcontent/
-----------------------------------------------------------------<=
/span>
--001a1134f2085dbb94053029224b-- From nobody Fri Apr 29 07:42:44 2016 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7AC12D0ED for ; Fri, 29 Apr 2016 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gsmasso.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak8OejW2bGaI for ; Fri, 29 Apr 2016 07:42:40 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0046.outbound.protection.outlook.com [104.47.0.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E689A12D0B5 for ; Fri, 29 Apr 2016 07:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iPWVRFoPHe8S1H3kb3wp+Y4KCqc2j+msMZpSwDHXwXo=; b=M1iOJ/RC+ju/76/UNgW4Cuk0DtlAtFha0E+YzLfi2I6tpviMaemChejxXV+w+ZhtTFqRAK16tGL/BQ4fZcCzSHjBa4ajiJM/Y6yJbR188xNsaeH7/0ifOs39FKtX0deqleociKcG9azBOhTustchRwWbNpzyBihYCiq4/yN3ib8= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 29 Apr 2016 14:42:37 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0477.014; Fri, 29 Apr 2016 14:42:37 +0000 From: Natasha Rooney To: "slim@ietf.org" Thread-Topic: IETF 95 Minutes Thread-Index: AQHRoiVfbrts7MnfjUmSqLOaDqfrDg== Date: Fri, 29 Apr 2016 14:42:37 +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.3112) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [87.114.169.154] x-ms-office365-filtering-correlation-id: 33a9380f-22d1-46c5-81e2-08d3703c8217 x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2064; 5:kGLYlbRI974TuzZI9pTwuv+l7SoZJh37LIYwISHm7VFuSyWg4iIMDAmM3BTYlEAtE6jJpMS9+nDkPoN84H+Cc0/RQxgY7oiotPgvas6cEDTT/Gr2+jzDrOGPyP4IQ5H0IaMuFmOvNx6Y1y2z4YirdQ==; 24:Y7wRjeXfMwG2+3cAMUgoefOGhlGbjX4boP6/r9tCnoawf/I+u1k78DO1flcBz3Aco3HQhcsg62mw3f+pSUvB3Scgsd9Ct9ez+AyhxhhO69Q=; 7:jpg6Ld0vFtKb60Y7pXxHA2wp6tFfPpIZ+oFTyQhNbwVz77q3SCFuTspkjRnuEwNYbR80g1oD6XW9YLPRRMnUbT91YwG/HMpBVlvieGwXbpdIMu74nchKYJi0iBDtEQ39toWfE3tyqcfp+IRp496ZmM4evQNhfIuILv9NB4Gu9AFQYBKVFZ5nanM/u4L3Ur1E x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2064; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR0401MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2064; x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(5002640100001)(83716003)(5008740100001)(81166005)(3660700001)(122556002)(586003)(2906002)(3280700002)(11100500001)(1220700001)(1096002)(5004730100002)(6116002)(102836003)(3846002)(10400500002)(1730700002)(2501003)(189998001)(15975445007)(86362001)(16236675004)(57306001)(77096005)(2900100001)(5890100001)(450100001)(50226002)(19617315012)(110136002)(50986999)(229853001)(107886002)(19580395003)(19580405001)(106116001)(5640700001)(2351001)(87936001)(33656002)(36756003)(66066001)(92566002)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2064; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CD651981ABFA4586A2482FAAC4D527F1gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2016 14:42:37.1049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2064 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.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: 87.114.169.154 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: VI1PR0401MB2064.eurprd04.prod.outlook.com Archived-At: Subject: [Slim] IETF 95 Minutes X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 14:42:43 -0000 --_000_CD651981ABFA4586A2482FAAC4D527F1gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpTTElNIG1pbnV0ZXMgZnJvbSBJRVRGOTUgd2VyZSB1cGxvYWRlZCBhdCB0aGUg c3RhcnQgb2YgdGhlIHdlZWsgYW5kIGNhbiBiZSBmb3VuZCBiZWxvdzoNCg0K4oGDIE1pbnV0ZXM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L21pbnV0ZXMvbWludXRlcy05NS1z bGltDQrigYMgTWVldGluZyBNYXRlcmlhbHMgUGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nLzk1L21hdGVyaWFscy5odG1sLw0KDQpXZSBoYXZlIHNvbWUgYWN0aW9ucyBm cm9tIHRoZSBtZWV0aW5nLCBwbGVhc2Ugc2VlIHRoZXNlIGJlbG93Og0KDQpBQ1RJT046IFRoZXJl IHdhcyBhIGNhbGwgZm9yIHZvbHVudGVlcnMgdG8gaGVscCB0ZXN0IG11bHRpcGFydC9tdWx0aWxp bmd1YWwgb24gbW9yZSBjbGllbnRzIChsYXN0IGVtYWlsIG9uIGxpc3QpDQpQZXJzb246IEFsbA0K DQpBQ1RJT046IHBsZWFzZSBzZW5kIGFkZGl0aW9uYWwgdXNlIGNhc2VzIGFuZCBzdWdnZXN0ZWQg Y2hhbmdlcyBmb3IgdGhlIHVzZSBjYXNlIGRvY3VtZW50IHRvIHRoZSBsaXN0Lg0KUGVyc29uOiBB bGwNCg0KQUNUSU9OOiB1cGRhdGUgdXNlIGNhc2UgZG9jdW1lbnQgd2l0aCBzdWJtaXR0ZWQgY2Fz ZXMgb24gZ2l0aHViIGFuZCBvbi1saXN0Lg0KUGVyc29uOiBOYXRhc2hhDQoNCkFDVElPTjogYXNr IGdyb3VwIGZvciBjb25zZW5zdXMgb24gZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFu LWxhbmd1YWdlIChhbiBlbWFpbCB3aWxsIGJlIHNlbnQgc2hvcnRseSBhZnRlciBjaGFpcnMgZGlz Y3Vzc2lvbikNClBlcnNvbjogQ2hhaXJzDQoNClRoYW5rcyBldmVyeW9uZSENCg0KTmF0YXNoYQ0K DQoNCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBXM0Mg JiBJRVRGIHwgR1NNQSB8IG5yb29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+ IHwgKzQ0ICgwKSA3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBn c20ub3JnPG1haWx0bzpucm9vbmV5QGdzbS5vcmc+DQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMg YXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5 IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBt dXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNo b3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0 IDIwNyAzNTYgMDYwMCBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4NCg== --_000_CD651981ABFA4586A2482FAAC4D527F1gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <1EBA9C5FA50FC54FAF9D40CB616F8345@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xv cjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+PC9zcGFuPkhpIGFsbCE8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpTTElNIG1pbnV0ZXMgZnJvbSBJRVRGOTUgd2VyZSB1cGxvYWRlZCBh dCB0aGUgc3RhcnQgb2YgdGhlIHdlZWsgYW5kIGNhbiBiZSBmb3VuZCBiZWxvdzo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIiBjbGFzcz0i Ij48L3NwYW4+4oGDPHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZSIgY2xhc3M9IiI+DQo8L3Nw YW4+TWludXRlczogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUv bWludXRlcy9taW51dGVzLTk1LXNsaW0iIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTUvbWludXRlcy9taW51dGVzLTk1LXNsaW08L2E+IDxiciBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiIGNsYXNzPSIiPjwvc3Bhbj7igYM8c3BhbiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIiBjbGFzcz0iIj4NCjwvc3Bhbj5NZWV0aW5nIE1hdGVyaWFs cyBQYWdlOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTUv bWF0ZXJpYWxzLmh0bWwvIiBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy85NS9tYXRlcmlhbHMuaHRtbC88L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KV2UgaGF2ZSBzb21lIGFjdGlvbnMgZnJvbSB0aGUgbWVldGluZywgcGxlYXNlIHNlZSB0aGVz ZSBiZWxvdzo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBQ1RJT046IFRoZXJlIHdhcyBh IGNhbGwgZm9yIHZvbHVudGVlcnMgdG8gaGVscCB0ZXN0IG11bHRpcGFydC9tdWx0aWxpbmd1YWwg b24gbW9yZSBjbGllbnRzIChsYXN0IGVtYWlsIG9uIGxpc3QpPGJyIGNsYXNzPSIiPg0KUGVyc29u OiBBbGw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBQ1RJT046IHBsZWFzZSBzZW5kIGFk ZGl0aW9uYWwgdXNlIGNhc2VzIGFuZCBzdWdnZXN0ZWQgY2hhbmdlcyBmb3IgdGhlIHVzZSBjYXNl IGRvY3VtZW50IHRvIHRoZSBsaXN0LjxiciBjbGFzcz0iIj4NClBlcnNvbjogQWxsPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQUNUSU9OOiB1cGRhdGUgdXNlIGNhc2UgZG9jdW1lbnQgd2l0 aCBzdWJtaXR0ZWQgY2FzZXMgb24gZ2l0aHViIGFuZCBvbi1saXN0LjxiciBjbGFzcz0iIj4NClBl cnNvbjogTmF0YXNoYTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFDVElPTjogYXNrIGdy b3VwIGZvciBjb25zZW5zdXMgb24mbmJzcDtkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVt YW4tbGFuZ3VhZ2UgKGFuIGVtYWlsIHdpbGwgYmUgc2VudCBzaG9ydGx5IGFmdGVyIGNoYWlycyBk aXNjdXNzaW9uKTwvc3Bhbj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTJweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPlBlcnNvbjogQ2hhaXJzPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzIGV2ZXJ5b25lITwvc3Bhbj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0YXNoYTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBX ZWIgYW5kIEludGVybmV0LCBXM0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1h aWx0bzpucm9vbmV5QGdzbWEuY29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208L2E+IHwg JiM0Mzs0NCAoMCkmbmJzcDs3NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTombmJz cDs8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5v cmc8L2E+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5OTsiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5 OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFyZWFzdC10aGVtZS1mb250 OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7OyBt c28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1HQjsgbXNv LWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBh cmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50 aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBh Y3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFu eW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAmIzQzOzQ0IDIwNyAzNTYg MDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CD651981ABFA4586A2482FAAC4D527F1gsmacom_--