From nobody Mon Apr 24 14:55:49 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2401294A6 for ; Mon, 24 Apr 2017 14:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXCpp21-_irW for ; Mon, 24 Apr 2017 14:55:44 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B75E131949 for ; Mon, 24 Apr 2017 14:55:44 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id j59so77237394uad.0 for ; Mon, 24 Apr 2017 14:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QGFIEkQGM1DcyXxQH/UQJYGJuVOJYa62gQsoXwpGmZY=; b=O3SIhFgrxpsCQIarRP8eNwc7uBg6hHXQ3loot2isexT4cQPVRcFBIbMGOE0s5M+l0f lH05xEQTbBXpkQ3SxVeu78DGw5QmBPz+DyVWpTu5GpBG/afXXfd+9dNtz7eSKBOHe6K5 SzUipmIvIwwkxU0Si/VqQ0PzBCaqGf/7Yn4U50l+9mELxa5Ff49HnKwuP/geDiWG1tX8 bNCoj4DlOCi6qrI5BKxP2zEnD4lITH3M4iqAYxplxAjnvPFkyApp38BTAyKpv9C6ZGrz 5q4wJkF2R09Gu8Hg8X9n4sr7nukP0Q1zeOaZdPjfRSIxooNM3CZpJNiAw5TEFVNPorPP Gb4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QGFIEkQGM1DcyXxQH/UQJYGJuVOJYa62gQsoXwpGmZY=; b=bs3Rn0LOb0uuL485kGLu2y5oZ8jhBrOnVBEzdsFER8IVedqazHKPia4YKKT3iUFwzv XCk6LG9TnUWNW3kxYCcnPsCj1jIM5Hj/4wguaTTCkijjF93M+IXz9OsNbv67+rdxBUnJ 6OeA4yLh20IwUqdam/kl2DhcALKAisLYyyJotfM9tBqxy/9s1cLl1vMdLY8+obYwniK7 X94sLPRbCAHXZ6xO97mkw7Pw9TjfcfAB8HYiOrzz++SpbBofHT2X4N75u3osdCHpm2ev Tes5nqXUYrD7qmm6jihEjC5zauvZonP79KuKAlK0QHRjPeXLCpsXaEd7QT9JojoQgFY9 EY8A== X-Gm-Message-State: AN3rC/45e0NenzUTqEGsjai9hmunklV3o+Z/9/rT10sdNEQIJYmSrCG1 8Lek4ck83qlwR8ZF98Zitwt29tcz+xnkCU0= X-Received: by 10.159.52.77 with SMTP id s13mr14723246uab.124.1493070943346; Mon, 24 Apr 2017 14:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 14:55:23 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 24 Apr 2017 14:55:23 -0700 Message-ID: To: Randall Gellens Cc: Adam Roach , slim@ietf.org, =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= , Natasha Rooney Content-Type: multipart/alternative; boundary=f403043eb7a433e6fd054df0abef Archived-At: Subject: Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:55:47 -0000 --f403043eb7a433e6fd054df0abef Content-Type: text/plain; charset=UTF-8 Randall Gellens said: "The WG explicitly decided to take routing out of scope to advance the simple proposal in the draft." [BA] While it is correct that the WG decided to leave routing out of scope for this document, the text does say anything about this, so that even an expert reader could be confused. Could we add some clarifying text? Adam Roach said: "I'll note that much of this can be fixed if the syntax is collapsed" [BA] I didn't see a reply to Adam's suggestion, which aside from the syntax issues would address concerns about SDP size. On Tue, Mar 28, 2017 at 4:54 PM, Randall Gellens wrote: > At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote: > > Bernard and Natasha, >> >> We're forwarding this message to you based on our conversation at the >> IANA Services desk. Please contact Adam Roach and Flemming Andreasen for >> additional information. >> Thank you, >> >> Sabrina >> >> ---- >> >> From: "Adam Roach" >> CC: "mmusic-chairs@tools.ietf.org" , " >> mmusic@ietf.org" , slim@ietf.org >> To: draft-ietf-slim-negotiating-human-language@tools.ietf.org >> Date: Tue, 7 Mar 2017 13:03:00 -0600 >> Subject: SDPDIR Review: Review of draft-ietf-slim-negotiating-hu >> man-language-08 >> Download (untitled) >> / >> with headers >> >> text/plain 3.9KiB >> Authors of draft-ietf-slim-negotiating-human-language -- >> >> I have reviewed this document on behalf of the SDP directorate [1]. >> Please wait for direction from your document shepherd or AD before >> posting a new version of the draft. >> >> It is my opinion that the document, as presently written, is too >> ambiguous to publish, for the reasons explained below. >> >> Aside -- I have a concern that negotiating language in SDP rather >> than SIP makes it necessary for proxies to look into SDP to make >> routing decisions, which is a pretty substantial layer violation >> (keep in mind, for example, that SIP was originally envisioned to >> contain S/MIME encrypted bodies, which would render the SDP >> unreadable by proxies). However, I note that section 5.1 indicates >> that this has issue been litigated in the working group already, and >> that it chose to do things in the way documented in the current draft. >> > > Negotiation in SDP vs SIP was extensively debated for a couple of years, > and Flemming was part of that discussion. The WG explicitly decided to > take routing out of scope to advance the simple proposal in the draft. > > > Leaving the layering issue aside, I find the proposed syntax to be >> confusing and potentially ambiguous. In particular, the draft does not >> address what it would mean if an implementation added "*" to the end of >> some language attributes, but omitted it from others; and, at the same >> time, it does not preclude senders from doing so. >> > > The draft explicitly says that an asterisk need only be appended to any > attribute value: > > An asterisk appended to any value indicates a > request by the caller to not fail the call if there is no language in > common. > ... > The mechanism for indicating this preference is that, in an offer, if > the last character of any of the 'hlang-recv' or 'hlang-send' values > is an asterisk, this indicates a request to not fail the call. The > called party MAY ignore the indication, e.g., for the emergency > services use case, regardless of the absence of an asterisk, a PSAP > will likely not fail the call; some call centers might reject a call > even if the offer contains a language with an asterisk. > > > Additionally, the descriptive text doesn't have any explanation that >> adjacent language tag pairs are somehow related to each other; however, >> there is an example whose accompanying text makes a strong implication >> that such pairing is intended: >> >> Hide quoted text >> >>> An offer requesting spoken Spanish both ways (most preferred), spoken >>> Basque both ways (second preference), or spoken English both ways >>> (third preference). The offer further requests that the call proceed >>> even if the callee does not support any of the languages: >>> >>> m=audio 49250 RTP/AVP 20 >>> a=hlang-send:es* >>> a=hlang-recv:es* >>> a=hlang-send:eu* >>> a=hlang-recv:eu* >>> a=hlang-send:en* >>> a=hlang-recv:en* >>> >> > I'm not following what you mean. There is no grouping or pairing nor > restrictions on which languages can be used with which others. The draft > presents a simple mechanism to enable basic language negotiation with > media, it does not attempt to capture the rich complexity of human > interactions or polylinguism. > > > Until this example, I would have assumed that an es/en pairing would be >> okay here; but the text implies that this would not be allowed. While >> en/es isn't necessarily a good example, I'll point out that I've seen a >> number of in-person conversations in which one person spoke Norwegian >> while the other spoke Swedish, with little apparently difficulty >> conversing. >> >> The document needs more text that talks about how send and receive >> languages are paired (is the example actually correct?), or it needs to >> make clear that such pairing is not part of the mechanism. It also needs >> clearer rules around use of "*", including specification of the intended >> behavior when its presence is inconsistent with a media section. >> >> I'll note that much of this can be fixed if the syntax is collapsed so >> that each media section can have at most one hlang-send and one >> hlang-receive, each of which contain a list of one or more languages >> that can be sent or received. This is also much more consistent with the >> way SDP attributes are used in general. The presence of a "*" token on >> that line would indicate the "call should happen even without matching >> languages" characteristic; since there is only one place to add this >> indicator, the ambiguity of some lines indicating it and others not >> disappears. The preceding example would collapse to: >> >> m=audio 49250 RTP/AVP 20 >> a=hlang-send:es eu en * >> a=hlang-recv:es eu en * >> >> ...and the example text would be revised to remove the implication that >> *sending* "es" necessarily implies *receiving* "es". >> >> I'll further note that the majority of SDP libraries I've worked with >> would make accessing the all-on-one-line format easier than >> one-line-per-language as well. >> >> To be clear: the issues I find problematic are (1) ambiguity around use >> of "*", and (2) the implication of pairing adjacent attributes with each >> other in the example without any parallel specification text. My >> proposed change is intended to be helpful, although there are clearly >> other solutions that address the issues I have identified. >> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > People that are really very weird can get into sensitive > positions and have a tremendous impact on history. > --then U.S. Vice President Dan Quayle > --f403043eb7a433e6fd054df0abef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Randall Gellens said:=C2=A0

"The WG explicitly decided to take routing out o= f scope to advance the simple proposal in the draft."

[BA] While it is correct that the WG decided to leave routi= ng out of scope for this document, the text does say anything about this, s= o that even an expert reader could be confused. Could we add some clarifyin= g text?=C2=A0

Adam Roach said:=C2=A0
"I'll note that much = of this can be fixed if the syntax is collapsed"

=
[BA] I didn't see a reply to Adam's=C2=A0suggestion, whi= ch aside from the syntax issues would address concerns about SDP size.

On Tue, Ma= r 28, 2017 at 4:54 PM, Randall Gellens <rg+ietf@randy.pensive.org<= /a>> wrote:
At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote= :

=C2=A0Bernard and Natasha,

=C2=A0We're forwarding this message to you based on our conversation at= the IANA Services desk. Please contact Adam Roach and Flemming Andreasen f= or additional information.
=C2=A0Thank you,

=C2=A0Sabrina

=C2=A0----

=C2=A0From:=C2=A0 "Adam Roach" <adam@nostrum.com>
=C2=A0CC:=C2=A0 =C2=A0 "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.i= etf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, slim@ietf.org
=C2=A0To:=C2=A0 =C2=A0 draft-ietf-slim-negotiating-human-language@tools.ietf.org
=C2=A0Date:=C2=A0 Tue, 7 Mar 2017 13:03:00 -0600
=C2=A0Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0SDPDIR Review: Review of draft-iet= f-slim-negotiating-human-language-08
=C2=A0Download (untitled)
=C2=A0/
=C2=A0with headers

=C2=A0text/plain 3.9KiB
=C2=A0Authors of draft-ietf-slim-negotiating-human-language --

=C2=A0I have reviewed this document on behalf of the SDP directorate [1]. =C2=A0Please wait for direction from your document shepherd or AD before =C2=A0posting a new version of the draft.

=C2=A0It is my opinion that the document, as presently written, is too
=C2=A0ambiguous to publish, for the reasons explained below.

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

Negotiation in SDP vs SIP was extensively debated for a couple of years, an= d Flemming was part of that discussion.=C2=A0 The WG explicitly decided to = take routing out of scope to advance the simple proposal in the draft.


=C2=A0Leaving the layering issue aside, I find the proposed syntax to be =C2=A0confusing and potentially ambiguous. In particular, the draft does no= t
=C2=A0address what it would mean if an implementation added "*" t= o the end of
=C2=A0some language attributes, but omitted it from others; and, at the sam= e
=C2=A0time, it does not preclude senders from doing so.

The draft explicitly says that an asterisk need only be appended to any att= ribute value:

=C2=A0 =C2=A0An asterisk appended to any value indicates a
=C2=A0 =C2=A0request by the caller to not fail the call if there is no lang= uage in
=C2=A0 =C2=A0common.
...
=C2=A0 =C2=A0The mechanism for indicating this preference is that, in an of= fer, if
=C2=A0 =C2=A0the last character of any of the 'hlang-recv' or '= hlang-send' values
=C2=A0 =C2=A0is an asterisk, this indicates a request to not fail the call.= =C2=A0 The
=C2=A0 =C2=A0called party MAY ignore the indication, e.g., for the emergenc= y
=C2=A0 =C2=A0services use case, regardless of the absence of an asterisk, a= PSAP
=C2=A0 =C2=A0will likely not fail the call; some call centers might reject = a call
=C2=A0 =C2=A0even if the offer contains a language with an asterisk.


=C2=A0Additionally, the descriptive text doesn't have any explanation t= hat
=C2=A0adjacent language tag pairs are somehow related to each other; howeve= r,
=C2=A0there is an example whose accompanying text makes a strong implicatio= n
=C2=A0that such pairing is intended:

=C2=A0Hide quoted text
=C2=A0An offer requesting spoken Spanish both ways (most preferred), spoken=
=C2=A0Basque both ways (second preference), or spoken English both ways
=C2=A0(third preference). The offer further requests that the call proceed<= br> =C2=A0even if the callee does not support any of the languages:

=C2=A0m=3Daudio 49250 RTP/AVP 20
=C2=A0a=3Dhlang-send:es*
=C2=A0a=3Dhlang-recv:es*
=C2=A0a=3Dhlang-send:eu*
=C2=A0a=3Dhlang-recv:eu*
=C2=A0a=3Dhlang-send:en*
=C2=A0a=3Dhlang-recv:en*

 I'm not following what you mean.=C2=A0 There is no grouping or pairing = nor restrictions on which languages can be used with which others.=C2=A0 Th= e draft presents a simple mechanism to enable basic language negotiation wi= th media, it does not attempt to capture the rich complexity of human inter= actions or polylinguism.


=C2=A0Until this example, I would have assumed that an es/en pairing would = be
=C2=A0okay here; but the text implies that this would not be allowed. While=
=C2=A0en/es isn't necessarily a good example, I'll point out that I= 've seen a
=C2=A0number of in-person conversations in which one person spoke Norwegian=
=C2=A0while the other spoke Swedish, with little apparently difficulty conv= ersing.

=C2=A0The document needs more text that talks about how send and receive =C2=A0languages are paired (is the example actually correct?), or it needs = to
=C2=A0make clear that such pairing is not part of the mechanism. It also ne= eds
=C2=A0clearer rules around use of "*", including specification of= the intended
=C2=A0behavior when its presence is inconsistent with a media section.

=C2=A0I'll note that much of this can be fixed if the syntax is collaps= ed so
=C2=A0that each media section can have at most one hlang-send and one
=C2=A0hlang-receive, each of which contain a list of one or more languages<= br> =C2=A0that can be sent or received. This is also much more consistent with = the
=C2=A0way SDP attributes are used in general. The presence of a "*&quo= t; token on
=C2=A0that line would indicate the "call should happen even without ma= tching
=C2=A0languages" characteristic; since there is only one place to add = this
=C2=A0indicator, the ambiguity of some lines indicating it and others not =C2=A0disappears. The preceding example would collapse to:

=C2=A0m=3Daudio 49250 RTP/AVP 20
=C2=A0a=3Dhlang-send:es eu en *
=C2=A0a=3Dhlang-recv:es eu en *

=C2=A0...and the example text would be revised to remove the implication th= at
=C2=A0*sending* "es" necessarily implies *receiving* "es&quo= t;.

=C2=A0I'll further note that the majority of SDP libraries I've wor= ked with
=C2=A0would make accessing the all-on-one-line format easier than
=C2=A0one-line-per-language as well.

=C2=A0To be clear: the issues I find problematic are (1) ambiguity around u= se
=C2=A0of "*", and (2) the implication of pairing adjacent attribu= tes with each
=C2=A0other in the example without any parallel specification text. My
=C2=A0proposed change is intended to be helpful, although there are clearly=
=C2=A0other solutions that address the issues I have identified.


--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
People that are really very weird can get into sensitive
positions and have a tremendous impact on history.
=C2=A0 =C2=A0--then U.S. Vice President Dan Quayle

--f403043eb7a433e6fd054df0abef-- From nobody Mon Apr 24 14:58:01 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5FA120227 for ; Mon, 24 Apr 2017 14:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ciblGmCLDYVf for ; Mon, 24 Apr 2017 14:57:52 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BA013150C for ; Mon, 24 Apr 2017 14:57:52 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 110so23100726uas.3 for ; Mon, 24 Apr 2017 14:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bfNJ2b3cd16w41LYWN2ri9d33sxJlJMfF6wujhhwsj8=; b=GcoDhP3/Cr9Xrl1OrWefNvZF8N4u+Jc61XIcbjjfdE+yeapbzPn1RCo28jKzlpZ7Fh /kH/5aM27/QJ03EJPHBAe5HiqNDOxSrYSWpkzO427pvAPWrQZtmvHpk2m5T/zZgZEv63 T2OZxIPm+E+g+ZOKb/v8F7A3pfNbcRPCB1sLfjEaI7g31+c5k03tl9drtH6sVb/NPj3O 0Ap7GrLuQYKeMal6d/yBsrdY4Xz9H+IY9qt1vfsmsKTpInChMWY8iBklKOfqrGIq05vQ lVnCXG0/L7q1DCHOiGfL4jZTHkheNd72qPE8etF1Qagjzbp9pvit0Ad18gXP0hjdKvc3 t/zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bfNJ2b3cd16w41LYWN2ri9d33sxJlJMfF6wujhhwsj8=; b=BvIZTbQi81RnpmKySmj2sdFSvnNq4d8jJNMO20JO6UWvAgWXUeItT/26PuPn+IuaWH Y8uUYmNocP4/LLJPhMr4BzzstdO9WfbdnUx9wP4c536DmagUuobtexBqugFLGplEREWo NyXq4VgH/l/8ea3JCX2aogI0J86Z0cwiHD9FsTM9iyL3giP8I/teTE2mLNFCivZvdRkf txx9i5iXGAislSp/3LnR20zXrZiWnA5fY2Q7raM5PHhO1KfTkwR2/Q+jnY+cc9GXbmWG dPLkG799RecoKCS6KR1qg9NSg3nWcHb/+sRQGqWOWm+a9ZnAV2JxoAIdSFBu4o5IdHKv eHcQ== X-Gm-Message-State: AN3rC/7AdCYOrNZ4d3jylAsrFyPDQuGEKSGs/wNBpV+5gFS1IwfIkoQU /v1QMEEQ4BtKACd/nwHszCso9B4qrg== X-Received: by 10.159.37.1 with SMTP id 1mr14894855uaz.131.1493071071320; Mon, 24 Apr 2017 14:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 14:57:30 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 24 Apr 2017 14:57:30 -0700 Message-ID: To: Randall Gellens Cc: Natasha Rooney , "slim@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c122e4cd4a314054df0b2d7 Archived-At: Subject: Re: [Slim] Ticket 31 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:57:55 -0000 --94eb2c122e4cd4a314054df0b2d7 Content-Type: text/plain; charset=UTF-8 Randall said: "This has already been discussed on the list and fixed in the draft. The draft added text suggesting which SIP response code to use, and added a SIP warning code to the IANA registry. IANA was informed of the change. The current draft includes in Section 5.3:" [BA] I believe we should close Ticket 31. On Tue, Mar 28, 2017 at 4:41 PM, Randall Gellens wrote: > This has already been discussed on the list and fixed in the draft. The > draft added text suggesting which SIP response code to use, and added a SIP > warning code to the IANA registry. IANA was informed of the change. The > current draft includes in Section 5.3: > > If the call is rejected due to lack of any languages in common, it is > suggested to use SIP response code 488 (Not Acceptable Here) or 606 > (Not Acceptable) [RFC3261] and include a Warning header field > [RFC3261] in the SIP response. The Warning header field contains a > warning code of [TBD: IANA VALUE, e.g., 308] and a warning text > indicating that there are no mutually-supported languages; the text > SHOULD also contain the supported languages and media. > > Example: > > Warning: [TBD: IANA VALUE, e.g., 308] proxy.example.com > "Incompatible language specification: Requested languages not > supported. Supported languages are: es, en; supported media > are: audio, text." > > And in Section 6.2 (within the IANA Considerations section): > > 6.2. Warn-Codes Sub-Registry of SIP Parameters > > IANA is requested to add a new value in the warn-codes sub-registry > of SIP parameters in the 300 through 329 range that is allocated for > indicating problems with keywords in the session description. The > reference is to this document. The warn text is "Incompatible > language specification: Requested languages not supported. Supported > languages and media are: [list of supported languages and media]." > > --Randy > > > At 8:14 PM +0000 3/28/17, Natasha Rooney wrote: > > https://trac.ietf.org/trac/slim/ticket/31#comment:1 >> >> Hi all! >> >> The ticket review continues! Ticket 31 addresses whether there is a need >> for a SIP code response for a call failure. Checking the IANA SIP registry >> is does not seem like there is a response code for language negotiation >> failure. Shall we request that a new one be added, if so, what should it be? >> >> >> > parameters.xhtml#sip-parameters-7>https://www.iana.org/ >> assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-7 >> >> Thanks! >> >> >> Natasha Rooney | Internet Engineering Director | Internet and Web Team | >> Technology | GSMA | nrooney@gsma.com | +44 (0) >> 7730 219 765 | @thisNatasha | Skype: nroone >> y@gsm.org >> >> This email and its attachments are intended for the above named only and >> may be confidential. If they have come to you in error you must take no >> action based on them, nor must you copy or show them to anyone; please >> reply to this email or call +44 207 356 0600 and highlight the error. >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If Richard Branson had worn a pair of steel-rimmed glasses, a > double-breasted suit and shaved off his beard, I would have > taken him seriously. As it was I couldn't.... > --Lord King, Chairman, British Airways > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --94eb2c122e4cd4a314054df0b2d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Randall said:=C2=A0

"This has already been discussed on the list and fixed= in the draft. The draft added text suggesting which SIP response code to u= se, and added a SIP warning code to the IANA registry.=C2=A0 IANA was infor= med of the change.=C2=A0 The current draft includes in Section 5.3:&= quot;

[BA] I believe we should close Ticket 31.=C2= =A0

On= Tue, Mar 28, 2017 at 4:41 PM, Randall Gellens <rg+ietf@randy.pens= ive.org> wrote:
This has al= ready been discussed on the list and fixed in the draft. The draft added te= xt suggesting which SIP response code to use, and added a SIP warning code = to the IANA registry.=C2=A0 IANA was informed of the change.=C2=A0 The curr= ent draft includes in Section 5.3:

=C2=A0 =C2=A0If the call is rejected due to lack of any languages in common= , it is
=C2=A0 =C2=A0suggested to use SIP response code 488 (Not Acceptable Here) o= r 606
=C2=A0 =C2=A0(Not Acceptable) [RFC3261] and include a Warning header field<= br> =C2=A0 =C2=A0[RFC3261] in the SIP response.=C2=A0 The Warning header field = contains a
=C2=A0 =C2=A0warning code of [TBD: IANA VALUE, e.g., 308] and a warning tex= t
=C2=A0 =C2=A0indicating that there are no mutually-supported languages; the= text
=C2=A0 =C2=A0SHOULD also contain the supported languages and media.

=C2=A0 =C2=A0Example:

=C2=A0 =C2=A0 =C2=A0 Warning:=C2=A0 [TBD: IANA VALUE, e.g., 308] proxy.examp= le.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Incompatible language specification= : Requested languages not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0supported.=C2=A0 Supported languages are:= es, en; supported media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are: audio, text."

And in Section 6.2 (within the IANA Considerations section):

6.2.=C2=A0 Warn-Codes Sub-Registry of SIP Parameters

=C2=A0 =C2=A0IANA is requested to add a new value in the warn-codes sub-reg= istry
=C2=A0 =C2=A0of SIP parameters in the 300 through 329 range that is allocat= ed for
=C2=A0 =C2=A0indicating problems with keywords in the session description.= =C2=A0 The
=C2=A0 =C2=A0reference is to this document.=C2=A0 The warn text is "In= compatible
=C2=A0 =C2=A0language specification: Requested languages not supported.=C2= =A0 Supported
=C2=A0 =C2=A0languages and media are: [list of supported languages and medi= a]."

--Randy


At 8:14 PM +0000 3/28/17, Natasha Rooney wrote:

=C2=A0https://trac.ietf.org/trac/slim/tick= et/31#comment:1

=C2=A0Hi all!

=C2=A0The ticket review continues! Ticket 31 addresses whether there is a n= eed for a SIP code response for a call failure. Checking the IANA SIP regis= try is does not seem like there is a response code for language negotiation= failure. Shall we request that a new one be added, if so, what should it b= e?


 <https://www= .iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-par= ameters-7>https://www.iana.org/assignments/sip-parameters/sip-parame= ters.xhtml#sip-parameters-7

=C2=A0Thanks!


=C2=A0Natasha Rooney | Internet Engineering Director | Internet and Web Tea= m | Technology | GSMA | <mailto:nrooney@gsma.com>nrooney@gsma.com | +44 (0) 7730= 219 765 | @thisNatasha | Skype: <mailto:nrooney@gsm.org>nrooney@gsm.org

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


 =C2=A0_______________________________________________
=C2=A0SLIM mailing list
=C2=A0SLIM@ietf.org<= br> =C2=A0https://www.ietf.org/mailman/listinfo/slim<= br>


--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
If Richard Branson had worn a pair of steel-rimmed glasses, a
double-breasted suit and shaved off his beard, I would have
taken him seriously. As it was I couldn't....
=C2=A0 =C2=A0 =C2=A0 =C2=A0--Lord King, Chairman, British Airways

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

--94eb2c122e4cd4a314054df0b2d7-- From nobody Mon Apr 24 15:00:13 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45315131952 for ; Mon, 24 Apr 2017 15:00:12 -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 YdJg3_9KGTyG for ; Mon, 24 Apr 2017 15:00:00 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DA613194C for ; Mon, 24 Apr 2017 14:59:59 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 198so25034573vkk.2 for ; Mon, 24 Apr 2017 14:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GH05KdqqD15iLLo8AfsvHx8C4yslX2rsKQnZ2/rbxzA=; b=eX+j9f3tAb8eQonaTQ8spPUTvainkSNFd9avM06A0FmDK+UdHEzOtuH3YKTf/VrkFa Sg64B42Ki4CehrP1H48vh9Ki4MBrZuknOvbcAu1I+uaxu8PHVUovaBZH2rKrcZBKZ1bi /h7vMcNVPj2Vu99k/Mws8YHtRLdmWc5XRxLnYrbXApKuK52WyOH8vGYAqK1MPU9JMX+l UVWfAVecxnQqB5vLr53fnGHhEpMcD75z1s2JJnoWv/x1f21D/ZF/DquDBOiDeKHmtmQp tZK4ZVjVn+l/NelHy125Jq/J1MDw5Z1gRZ40yOmURL3L7GW9IzwKJo7Q3j48/xjT5xsG u0Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GH05KdqqD15iLLo8AfsvHx8C4yslX2rsKQnZ2/rbxzA=; b=op1dPkGMQw6E5TpxSIPwPjqgwLdR3K0dtIkDewCsd0xGfFtHn6SX7m7r/vMRo0+gGo BApGlIBe7wBV2aQvnA4t5/zbJLb/V7FGUnLNRsMQ7vLClTevzpOOa+hjxug5+jJowEe7 WM4qNsIvAaDDtQNOPzUrzAyxOAR/RMB+3bQ4k+joAT3k9gzl1M630cdb/MCNPGJgdFI0 T7AwHD3d7T3fbkR94H28CKONJofFMB9YgJzWVCta6h4uWtUk02oNkSgKu7HHsLrHTfg+ nCEW8RYCJ56WQSYy2mhnwnHNlnpBuyxGza+5wJEbUL6M3vDADiRTI+Mvo4GmdfCvIUbm x7ig== X-Gm-Message-State: AN3rC/58j1fmtNKDj9qsNJN4p6YRrc1g8/srGXIPAr96LztHTRE1np/Z 3/KL6gO06PSsMqOG+zGDPIiM9vOHkubV X-Received: by 10.31.238.74 with SMTP id m71mr3891281vkh.109.1493071198874; Mon, 24 Apr 2017 14:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 14:59:38 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 24 Apr 2017 14:59:38 -0700 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Cc: slim@ietf.org Content-Type: multipart/alternative; boundary=001a114db14e6f0292054df0baa0 Archived-At: Subject: Re: [Slim] Ticket 29 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:00:12 -0000 --001a114db14e6f0292054df0baa0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right. Randall - can we fix the spelling so that we can close Ticket 29? On Wed, Mar 29, 2017 at 12:18 PM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > > > Den 2017-03-29 kl. 01:37, skrev Randall Gellens: > >> The revised draft (-08, published 2/26) added "MUX Category: NORMAL" to >> the IANA registrations. This was per IANA review and my own review of >> draft-ietf-mmusic-sdp-mux-attributes. >> > Right. > but the spelling should be: > Mux Category: NORMAL > >> >> >> The draft did not change ""Usage Level: media". >> > Right. > There is a draft for transport of real-time text in a WebRTC data channel= , > so the addition of likely ",dsca(t140)" will be needed eventually, but I > think we need to wait with that addition until the draft is approved and > the subprotocol name surely assigned. > > /Gunnar > > >> >> --Randy >> >> At 8:01 PM +0000 3/28/17, Natasha Rooney wrote: >> >> Hi all, >>> >>> Bernard and I are going through open issues on the drafts today at >>> IETF98. With regards to ticket 29, we would like to know if there is >>> working group support for the following change? Please look at the tick= et >>> if you require more info: >>> >>> https://trac.ietf >>> .org/trac/slim/ticket/29 >>> >>> ******** Suggested Change ********* >>> Section 6 has the form for attribute registration by IANA. There are a >>> couple of fields missing that will be important for use of the >>> specification in the WebRTC environment. Include these fields if that i= s >>> allowable according to current IANA procedures and if that does not del= ay >>> the publication of this draft. These fields are needed for use of text >>> media in WebRTC. >>> >>> Change suggested: >>> >>> "Usage Level: media" >>> to: >>> "Usage Level: media, dcsa(subprotocol)" >>> >>> Insert in two locations in the registration forms: >>> "Mux Category: NORMAL" >>> >>> This email and its attachments are intended for the above named only >>> and may be confidential. If they have come to you in error you must tak= e no >>> action based on them, nor must you copy or show them to anyone; please >>> reply to this email or call +44 207 356 0600 and highlight the error. >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >>> >> >> >> > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim > --001a114db14e6f0292054df0baa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right.=C2=A0

Randall - can we fix the s= pelling so that we can close Ticket 29?

On Wed, Mar 29, 2017 at 12:18 PM, Gunnar = Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote= :


Den 2017-03-29 kl. 01:37, skrev Randall Gellens:
The revised draft (-08, published 2/26) added "MUX Category:=C2=A0 NOR= MAL" to the IANA registrations.=C2=A0 This was per IANA review and my = own review of draft-ietf-mmusic-sdp-mux-attributes.
 Right.
but the spelling should be:
Mux Category: NORMAL


The draft did not change ""Usage Level: media".
 Right.
There is a draft for transport of real-time text in a WebRTC data channel, = so the addition of likely ",dsca(t140)" will be needed eventually= , but I think we need to wait with that addition until the draft is approve= d and the subprotocol name surely assigned.

/Gunnar



--Randy

At 8:01 PM +0000 3/28/17, Natasha Rooney wrote:

=C2=A0Hi all,

=C2=A0Bernard and I are going through open issues on the drafts today at IE= TF98. With regards to ticket 29, we would like to know if there is working = group support for the following change? Please look at the ticket if you re= quire more info:

<https://trac.ietf.org/trac/slim/ticket/29><= a href=3D"https://trac.ietf.org/trac/slim/ticket/29" rel=3D"noreferrer" tar= get=3D"_blank">https://trac.ietf.org/trac/slim/ticket/29

=C2=A0******** Suggested Change *********
=C2=A0Section 6 has the form for attribute registration by IANA. There are = a couple of fields missing that will be important for use of the specificat= ion in the WebRTC environment. Include these fields if that is allowable ac= cording to current IANA procedures and if that does not delay the publicati= on of this draft. These fields are needed for use of text media in WebRTC.<= br>
=C2=A0Change suggested:

=C2=A0"Usage Level: media"
=C2=A0to:
=C2=A0"Usage Level: media, dcsa(subprotocol)"

=C2=A0Insert in two locations in the registration forms:
=C2=A0"Mux Category: NORMAL"

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


=C2=A0_______________________________________________
=C2=A0SLIM mailing list
=C2=A0SLIM@ietf.org<= br> =C2=A0https://www.ietf.org/mailman/listinfo/slim<= br>



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


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

--001a114db14e6f0292054df0baa0-- From nobody Mon Apr 24 15:14:02 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F04126B71 for ; Mon, 24 Apr 2017 15:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQyVYwX8Aejl for ; Mon, 24 Apr 2017 15:13:59 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EF1120227 for ; Mon, 24 Apr 2017 15:13:58 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id f10so120741592uaa.2 for ; Mon, 24 Apr 2017 15:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5YsKkjzg1T6fezOWqyUtPNxfzaRotZHZBgKcjDBiJxg=; b=g16P5XDWLyUswd0lSDBOxv0oU9eJjBYSJOxdtKS97M2mUuWP3shpwgENGTo7FBPcSF IV18pcwiTEye8ydpmK9y44Gj3y0Zw6I6KZAR4McY87rS6sxGdrL9zkqaSgCn4hH5kz9G FLglzUdJCdHqlrW3MvISrtqnqK+bzi8EOzWSu+7b/X0EppBD62EBGqK6dNk8bPddy9zQ BPgY+4Sg1n+hjcUyu+jRQDQpWThLytJ0I2xSNd1ndKQ82c+Na377wewObrU+tyVp6EUA HHrcM2e7BuTqDJw+3ugKC9o0A7XXTQ625923Q0jOIhIdPK2J86gkOBTAGXgFNB6SZ3O7 BOOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5YsKkjzg1T6fezOWqyUtPNxfzaRotZHZBgKcjDBiJxg=; b=nnN3euzFt9FrXg/zzfdBIz3AgqIIXU/FfW6tVyHvt+WcA6Q+g7gleAGoy28ddQFpdg 2/R30YQZja5GJwnOQMWmE38+8BSBo1Wa0jfGG0jg9ui2wDOZXsaJGVx9B43GlOLLWYVD rUllH+013dkMbI+Oh2HVDhJuleh7xc5VHQ7DfXH9UOsGb4hG0SBNo+mIvo8u7KMATkZE buaWeBYqj5ZCQTHja5sex/2OHIxXCewNImfv97PqwFI69WtXlYYixIvCKIEbTWTUesl8 mK3QX9u50bmJ8FNIEko1wmkydYMgqiKGtawX7f7ptGltsgcbJkucuy00FIkJJvOYpFRt +e1A== X-Gm-Message-State: AN3rC/6Rm8nR5faZOQwcIprYByzChiXuPM2teQ0XvE4IQr+qs7srjb7u c9dvwWUckz02b+PZ4/ybqyVclx/vwbRamcw= X-Received: by 10.159.49.8 with SMTP id m8mr1443213uab.64.1493072037836; Mon, 24 Apr 2017 15:13:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 15:13:37 -0700 (PDT) In-Reply-To: <7b110177-5bc9-ac41-5819-ec5354a4dced@omnitor.se> References: <7b110177-5bc9-ac41-5819-ec5354a4dced@omnitor.se> From: Bernard Aboba Date: Mon, 24 Apr 2017 15:13:37 -0700 Message-ID: To: Randall Gellens Cc: slim@ietf.org, Natasha Rooney , Adam Roach , Alexey Melnikov , =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=f403045e2576707c16054df0ec66 Archived-At: Subject: Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters) and issue 37 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:14:01 -0000 --f403045e2576707c16054df0ec66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gunnar said: "I notice that the comments and solution proposal on the syntax concerns fr= om the IANA review has a lot in common with Issue 34. https://trac.ietf.org/trac/slim/ticket/34 Both propose a one-line format for all languages in one media and direction= , and both are puzzled by the diffuse placement rules for the asterisk parameter. A solution could be searched on these together." [BA] Yes, there does appear to be commonality in these 3 independent reviews - which is what lead to the suggestion that the draft go back to the WG. Randall -- is there some obvious reason why a syntax collapse cannot be considered? On Thu, Mar 30, 2017 at 2:14 AM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > I notice that the comments and solution proposal on the syntax concerns > from the IANA review has a lot in common with Issue 34. > > https://trac.ietf.org/trac/slim/ticket/34 > > Both propose a one-line format for all languages in one media and > direction, and both are puzzled by the diffuse placement rules for the > asterisk parameter. > > A solution could be searched on these together. > > Gunnar > > > Den 2017-03-28 kl. 22:31, skrev Sabrina Tanamal via RT: > >> Bernard and Natasha, >> >> We're forwarding this message to you based on our conversation at the >> IANA Services desk. Please contact Adam Roach and Flemming Andreasen for >> additional information. >> >> Thank you, >> >> Sabrina >> >> ---- >> >> From: "Adam Roach" >> CC: "mmusic-chairs@tools.ietf.org" , " >> mmusic@ietf.org" , slim@ietf.org >> To: draft-ietf-slim-negotiating-human-language@tools.ietf.org >> Date: Tue, 7 Mar 2017 13:03:00 -0600 >> Subject: SDPDIR Review: Review of draft-ietf-slim-negotiating-hu >> man-language-08 >> Download (untitled) >> / >> with headers >> >> text/plain 3.9KiB >> Authors of draft-ietf-slim-negotiating-human-language -- >> >> I have reviewed this document on behalf of the SDP directorate [1]. >> Please wait for direction from your document shepherd or AD before >> posting a new version of the draft. >> >> It is my opinion that the document, as presently written, is too >> ambiguous to publish, for the reasons explained below. >> >> Aside -- I have a concern that negotiating language in SDP rather >> than SIP makes it necessary for proxies to look into SDP to make >> routing decisions, which is a pretty substantial layer violation >> (keep in mind, for example, that SIP was originally envisioned to >> contain S/MIME encrypted bodies, which would render the SDP >> unreadable by proxies). However, I note that section 5.1 indicates >> that this has issue been litigated in the working group already, and >> that it chose to do things in the way documented in the current draft. >> >> >> Leaving the layering issue aside, I find the proposed syntax to be >> confusing and potentially ambiguous. In particular, the draft does not >> address what it would mean if an implementation added "*" to the end of >> some language attributes, but omitted it from others; and, at the same >> time, it does not preclude senders from doing so. >> >> Additionally, the descriptive text doesn't have any explanation that >> adjacent language tag pairs are somehow related to each other; however, >> there is an example whose accompanying text makes a strong implication >> that such pairing is intended: >> >> Hide quoted text >> >>> An offer requesting spoken Spanish both ways (most preferred), spoken >>> Basque both ways (second preference), or spoken English both ways >>> (third preference). The offer further requests that the call proceed >>> even if the callee does not support any of the languages: >>> >>> m=3Daudio 49250 RTP/AVP 20 >>> a=3Dhlang-send:es* >>> a=3Dhlang-recv:es* >>> a=3Dhlang-send:eu* >>> a=3Dhlang-recv:eu* >>> a=3Dhlang-send:en* >>> a=3Dhlang-recv:en* >>> >> Until this example, I would have assumed that an es/en pairing would be >> okay here; but the text implies that this would not be allowed. While >> en/es isn't necessarily a good example, I'll point out that I've seen a >> number of in-person conversations in which one person spoke Norwegian >> while the other spoke Swedish, with little apparently difficulty >> conversing. >> >> The document needs more text that talks about how send and receive >> languages are paired (is the example actually correct?), or it needs to >> make clear that such pairing is not part of the mechanism. It also needs >> clearer rules around use of "*", including specification of the intended >> behavior when its presence is inconsistent with a media section. >> >> I'll note that much of this can be fixed if the syntax is collapsed so >> that each media section can have at most one hlang-send and one >> hlang-receive, each of which contain a list of one or more languages >> that can be sent or received. This is also much more consistent with the >> way SDP attributes are used in general. The presence of a "*" token on >> that line would indicate the "call should happen even without matching >> languages" characteristic; since there is only one place to add this >> indicator, the ambiguity of some lines indicating it and others not >> disappears. The preceding example would collapse to: >> >> m=3Daudio 49250 RTP/AVP 20 >> a=3Dhlang-send:es eu en * >> a=3Dhlang-recv:es eu en * >> >> ...and the example text would be revised to remove the implication that >> *sending* "es" necessarily implies *receiving* "es". >> >> I'll further note that the majority of SDP libraries I've worked with >> would make accessing the all-on-one-line format easier than >> one-line-per-language as well. >> >> To be clear: the issues I find problematic are (1) ambiguity around use >> of "*", and (2) the implication of pairing adjacent attributes with each >> other in the example without any parallel specification text. My >> proposed change is intended to be helpful, although there are clearly >> other solutions that address the issues I have identified. >> >> /a >> >> ____ >> [1] https://www.ietf.org/iesg/directorate/sdp.html >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >> > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > --f403045e2576707c16054df0ec66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gunnar said:=C2=A0

"I notice that the comments and solution proposal on the sy= ntax concerns=C2=A0from the IANA review= has a lot in common with Issue 34.
https://trac.ietf.org/trac/slim/ticket/34
Both propose a one-line format for all= languages in one media and=C2=A0direct= ion, and both are puzzled by the diffuse placement rules for the=C2=A0= asterisk parameter.
A solution could be searched on these together."=
;

[BA] Yes, there does appear to be commonality i=
n these 3 independent reviews - which is what lead to the suggestion that t=
he draft go back to the WG.

Randall -- is there s=
ome obvious reason why a syntax collapse cannot be considered?



On Thu, Mar 30, 2017 at 2:14 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:
I notice that the comments and solution proposal on the synta= x concerns from the IANA review has a lot in common with Issue 34.

https://trac.ietf.org/trac/slim/ticket/34

Both propose a one-line format for all languages in one media and direction= , and both are puzzled by the diffuse placement rules for the asterisk para= meter.

A solution could be searched on these together.

Gunnar


Den 2017-03-28 kl. 22:31, skrev Sabrina Tanamal via RT:
Bernard and Natasha,

We're forwarding this message to you based on our conversation at the I= ANA Services desk. Please contact Adam Roach and Flemming Andreasen for add= itional information.

Thank you,

Sabrina

----

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

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

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

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

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


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

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

Hide quoted text
An offer requesting spoken Spanish both ways (most preferred), spoken
Basque both ways (second preference), or spoken English both ways
(third preference). The offer further requests that the call proceed
even if the callee does not support any of the languages:

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

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

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

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

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

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

/a

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

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

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


--f403045e2576707c16054df0ec66-- From nobody Tue Apr 25 11:25:45 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7A131764 for ; Tue, 25 Apr 2017 11:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc2eO4Dw41EG for ; Tue, 25 Apr 2017 11:25:40 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D0131755 for ; Tue, 25 Apr 2017 11:25:40 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id h2so137043703uaa.1 for ; Tue, 25 Apr 2017 11:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ufrqhOWwUV6+vPACi5fAdH/4y4zcJeVsa+1P3e9jeuc=; b=TD8JcB+1xt2X21pDh3H6bTjJoYEunRZIWKYh5Eo4FpQidDFwOisXgseI0XpA0a2/QX RPy9Uo1y5r7SAS3BRP8oFRzhQ8vOXbzF57iDFXt7uzNpDR+Ch+3ASFi3m/iulJw6Qwob GjMsKrCD0kyTyA6OSAYJVzbPBI9zmiOT2gJHigEXzApHPiSIX/gYjldGTyDMK3/U5Mj0 sF0qCDQ6GQ9OdwCX0/g/mD1IUgOOG2QeruBW7UoFmoBeIve0ki9NNiai9WoyRMAjQo5q Rg+Si9t/vzwfqLQgTKpoTLG2y1XDUNIQscPeCtFo+bTTe/8XSx4FYh3IqS2kZUAApJJS oKmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ufrqhOWwUV6+vPACi5fAdH/4y4zcJeVsa+1P3e9jeuc=; b=Q2Ye5jSHAgO4X1juEJkodLem3Ri0dkZ9A6Pg+NHO5d6JqW6v0CU8koxdJBGNCh1JN8 Tnwsq3P2YfbO9RLMgVZBtGL8B2AHDgimxAs2tKDlJSUzN8nDc4RoDEV0DkZtjST4ku+O xFOT+vRroGJuBZXzGU9IAMaG7b1sqeGmIvcX15zP5q5B8FGlRmd26inxFArLBLALmfxZ YDwe2HfZoX94ks7miNVei3SXNBbBNoU0xWUSSLwkZPIDKbkA0D3e3R4uBLsY863JxRdw OSfbH0fS0qFS50xcqF8zs9TJaWO3cPy3rYaMzVC+TRWIT8k+d21z8pjSKlIFpRSondAm BEsA== X-Gm-Message-State: AN3rC/7PTQxprM4mx3rgiLdZaHUcqvRoPTFzQMZSIPMUg1+zIZs2Gcxy 2arQHEq50EwTfFyfkGUM22SKATph606kjxI= X-Received: by 10.176.83.61 with SMTP id x58mr14692748uax.33.1493144739343; Tue, 25 Apr 2017 11:25:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Tue, 25 Apr 2017 11:25:18 -0700 (PDT) From: Bernard Aboba Date: Tue, 25 Apr 2017 11:25:18 -0700 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary=94eb2c19105ec973f2054e01d9ae Archived-At: Subject: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:25:44 -0000 --94eb2c19105ec973f2054e01d9ae Content-Type: text/plain; charset=UTF-8 Currently 10 Issues remain open from IETF Last Call: https://trac.ietf.org/trac/slim/report/1 These include: Ticket Summary Component Version Milestone Type Owner Status Created #27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017 #19 Use Media Type registration template multilangcontent enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016 #28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017 #32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017 #34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017 #35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017 #38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017 #39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017 #26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017 #29 Include more fields for attribute registration from 4566bis --94eb2c19105ec973f2054e01d9ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Currently 10 Issues remain open from IETF Last Call:<= /div>

These include= :=C2=A0
<= th style=3D"font-stretch:normal;font-size:11px;line-height:normal;text-alig= n:left;padding:2px 0.5em;border-width:1px;border-style:solid;border-color:r= gb(215,215,215) rgb(215,215,215) rgb(153,153,153);vertical-align:bottom;whi= te-space:nowrap;background-image:initial;background-position:initial;backgr= ound-size:initial;background-repeat:initial;background-origin:initial;backg= round-clip:initial;text-transform:capitalize">S= tatus= <= tr class=3D"gmail-color3-odd" style=3D"font-stretch:normal;line-height:norm= al;border-bottom:1px solid rgb(221,221,221);border-top:1px solid rgb(221,22= 1,221);background:rgb(251,251,251);border-right-color:rgb(221,221,221);bord= er-left-color:rgb(221,221,221);color:rgb(68,68,68)">
TicketSummaryCompon= entVersionMilestoneTypeOwnerCreated
#27The cases in the "Silly sta= tes" section 5.4 are not all silly.negotiating-human-language2.0milest= one1defectgunnar.hel= lstrom@omnitor.senewMar 22, 2017
#19Use Media Type registration temp= latemultilangcontentenhancementrfc.nik.t= omkinson@gmail.comassignedAug 17, 2016
#28= Examples section 5.5 requires= expansionnegotiating-human= -language2.0milestone1defectrg+ietf@randy.pensive.orgassigned= Mar 22, 2017
#32Audio/Video Coordinationnegotiating-human-language= 2.0milestone1= defectrg+ietf@randy.pens= ive.orgnewMar 22, 2017
#34Use the Accept-Language syntaxnegotiating-human-language2.0= milestone1defectrg+ietf@randy.pensive.orgassignedMar 22, 2017
#35Have an attri= bute to abbreviate the bidirectionally-symmetric casenegotiating-human-language2.0milestone1defectrg+ietf@randy.pensive.orgass= ignedMar 22, 2017
#38Routing out of scope= negotiating-human-language<= /td>1.0milestone1defectdraft-ietf-slim-negotiating-= human-language@ietf.orgnewApr 25, 2017
#39<= /a>Syntax Collapsenegotiating-human-language1.0= milestone1defectdraft-ietf-slim-negotiating-human-languag= e@ietf.orgnewApr 25, 2017
#26Make use of the asterisk modifier on media= level with session scope also for media level purposesnegotiating-human-language2.0milestone1enhancementgunnar.hellstrom@omnitor.senewMar 22, 2017
#29Include more fi= elds for attribute registration from 4566bis
<= /div>
--94eb2c19105ec973f2054e01d9ae-- From nobody Wed Apr 26 13:55:35 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA0127342 for ; Wed, 26 Apr 2017 13:55:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra_ggC5RYyA6 for ; Wed, 26 Apr 2017 13:55:14 -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 490D312EB24 for ; Wed, 26 Apr 2017 13:55:13 -0700 (PDT) X-Halon-ID: a16e6afa-2ac2-11e7-9f7f-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 26 Apr 2017 22:55:07 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se> Date: Wed, 26 Apr 2017 22:55:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3B64629157F82ECB8CC2D12A" Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:55:19 -0000 This is a multi-part message in MIME format. --------------3B64629157F82ECB8CC2D12A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Bernard, thanks for the summary. We need decisions on these issues and move on. How do you propose that decisions are taken? A brief comment on #38 - routing: My memory of the discussion and decision is that we would not describe the routing logic and actions, but we should aim at producing indications that would have high likelihood to be usable for routing calls to appropriate call parties. Thus it needs to be possible to interrogate the indications by proxies even if TLS is used. Regards Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------3B64629157F82ECB8CC2D12A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Bernard, thanks for the summary. We need decisions on these issues and move on.

How do you propose that decisions are taken?

A brief comment on #38 - routing: My memory of the discussion and decision is that we would not describe the routing logic and actions, but we should aim at producing indications that would have high likelihood to be usable for routing calls to appropriate call parties. Thus it needs to be possible to interrogate the indications by proxies even if TLS is used.


Regards

Gunnar



Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------3B64629157F82ECB8CC2D12A-- From nobody Wed Apr 26 14:15:18 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330F11294FD for ; Wed, 26 Apr 2017 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 61NCBYF_bmlL for ; Wed, 26 Apr 2017 14:15:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C6D127342 for ; Wed, 26 Apr 2017 14:15:15 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QLFCax084137 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 16:15:13 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , Bernard Aboba , slim@ietf.org References: <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se> From: Adam Roach Message-ID: Date: Wed, 26 Apr 2017 16:15:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:15:16 -0000 On 4/26/17 3:55 PM, Gunnar Hellström wrote: > > Bernard, thanks for the summary. We need decisions on these issues and > move on. > > How do you propose that decisions are taken? > > A brief comment on #38 - routing: My memory of the discussion and > decision is that we would not describe the routing logic and actions, > but we should aim at producing indications that would have high > likelihood to be usable for routing calls to appropriate call parties. > Thus it needs to be possible to interrogate the indications by proxies > even if TLS is used. > TLS is hop-by-hop in SIP (meaning it hides exactly nothing from proxies), so that's not an issue. The chances of S/MIME being broadly deployed in SIP do seem kind of slim, but thinking about what would happen if the body were encrypted is a good litmus test for "have I *really* messed up my layering?" Given that the direction selected by the WG is to represent language values in SDP, I think this document can *either* say that routing is 100% out of scope and unaddressed, *or* it can add some SIP-level header fields that bear on routing according to human languages. Anything that tries to split the difference is likely to cause architectural pain in the future, and an approach that I would counsel very strongly against. /a From nobody Wed Apr 26 20:11:48 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A41A1294B8 for ; Wed, 26 Apr 2017 20:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXBricATH6Y6 for ; Wed, 26 Apr 2017 20:11:46 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 57AE912741D for ; Wed, 26 Apr 2017 20:11:46 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id c198so5184984pfc.0 for ; Wed, 26 Apr 2017 20:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ItaIbgOunfdkXIQhAGKo7UEA8LR3emzRTu+ZqI5FhtU=; b=HcRPKfOPwBzmcPxGOKLkwrawqKfcQyVG3CpoTPg/YiMEsrtn7fsyTuFeJW2yrjjkz7 aw4y4Mo+86xa2Y/2rRgVnMFcSn0nkNZakA56/EDl/mzNwbI48ypuIDSO+qoCi6g3hGZv EZJydrNtq+FuG9dtHT3oTMIyHRNQwKsg2wu8c3udLDgjDjhwY4ROt1JsvBtLy29V7m+K NOIXy5xDN3xCa0ZqL/dv173Oo85mfvlYl3gEghrVCtBkqkeNsB+snRZyAxROu2O1WpUP 8Ny+uxi6XzA9EBAYxJF2tHe9npFlZft8CZxX3eYAFvjg1Y03XiPNxe9KOcxnXZgnx7YR mPQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ItaIbgOunfdkXIQhAGKo7UEA8LR3emzRTu+ZqI5FhtU=; b=LcXfuQW5qU+UwT0NM+uOs9l4IulYVBkFuH+2O8iGa6QdP7FiJbM2w9fzO3CLMU/0C5 8pyT1j6K448EqMmqi/cmYoSGbCZFJ0ohcA0mSOYFR6palEFfxACYeijx3w+UaI6Xllbe JwUzB+R//IOLnnvn82aSspLXrA6iEbUk/B6eu2boJw8226Xn9IOXgeul2KA5GBbLcF/V yyUjHeo9eJZ5uCiI6kLVioMHZycauplRJn6LtKt/rRpPkTmGwtJjFZxes+XXg+QiSUbv 7V8kI7CMqlvKYQ/trebmj4/ma6G3XFgNQ6rxngxR5ddb/CfhQBTXcqEDhK5zOn57Yw5L vYPg== X-Gm-Message-State: AN3rC/4QRHT4Rj19dOUP6DnjILU2OivVzp30VsHSXedD3HCMGag5c+ny aQdwxJtlGdZcOfjh2Z8= X-Received: by 10.84.222.129 with SMTP id x1mr4136809pls.44.1493262705750; Wed, 26 Apr 2017 20:11:45 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id x185sm1071363pfx.102.2017.04.26.20.11.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 20:11:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (14E304) In-Reply-To: Date: Wed, 26 Apr 2017 20:11:44 -0700 Cc: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= , slim@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9CCECC1F-464B-49F1-A71B-EBA394C4B7B2@gmail.com> References: <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se> To: Adam Roach Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 03:11:47 -0000 On Apr 26, 2017, at 14:15, Adam Roach wrote: >=20 > Given that the direction selected by the WG is to represent language value= s in SDP, I think this document can *either* say that routing is 100% out of= scope and unaddressed, *or* it can add some SIP-level header fields that be= ar on routing according to human languages.=20 [BA] Given that routing work is not in the current WG Charter, my suggestion= would be for the current document to say it is out of scope. But it might a= lso say that SIP-level header fields may be defined in future (if only to ma= ke it clear that the document is not suggesting SDP-based routing).= From nobody Thu Apr 27 02:23:09 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D411201F2 for ; Thu, 27 Apr 2017 02:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MARdimhehemu for ; Thu, 27 Apr 2017 02:23:05 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6955128896 for ; Thu, 27 Apr 2017 02:23:04 -0700 (PDT) X-Halon-ID: 1bd191cb-2b2b-11e7-b152-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 11:23:00 +0200 (CEST) To: Bernard Aboba , Adam Roach References: <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se> <9CCECC1F-464B-49F1-A71B-EBA394C4B7B2@gmail.com> Cc: slim@ietf.org From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <52039d11-d4ee-91d7-fcf4-b3fbff1f8cb5@omnitor.se> Date: Thu, 27 Apr 2017 11:22:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9CCECC1F-464B-49F1-A71B-EBA394C4B7B2@gmail.com> Content-Type: multipart/alternative; boundary="------------AEABD29DF01A6AEA356BD519" Archived-At: Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:23:08 -0000 This is a multi-part message in MIME format. --------------AEABD29DF01A6AEA356BD519 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2017-04-27 kl. 05:11, skrev Bernard Aboba: > On Apr 26, 2017, at 14:15, Adam Roach wrote: >> Given that the direction selected by the WG is to represent language values in SDP, I think this document can *either* say that routing is 100% out of scope and unaddressed, *or* it can add some SIP-level header fields that bear on routing according to human languages. > [BA] Given that routing work is not in the current WG Charter, my suggestion would be for the current document to say it is out of scope. But it might also say that SIP-level header fields may be defined in future (if only to make it clear that the document is not suggesting SDP-based routing). The charter is flexible about including routing aspects. It says: " Alternatives such as doing the media negotiation in SIP have been explored in the past and are out of scope (although SIP-based mechanisms may be introduced when routing considerations are addressed). The group's initial focus will not be on supporting language-based call routing decisions. Once the initial work is sufficiently progressed, the group may address call routing, with the timing at the judgment of the chairs. " I guess that the work cannot be considered "sufficiently progressed" yet. So we should not deal with routing. What we can do is to assume that an emergency service or call center application will put the call in an appropriate queue just based on SIP fields, and the UAs that have language capabilities matching the indications will answer. However, I do not see how we can have a UA deciding if it has the best match among available UAs so that it shall decide to answer the call. Section 9.2 of RFC 6443 says: " To enable media-sensitive routing, the call should include a Session Description Protocol (SDP) offer [RFC3264 ]." So, there is an assumption that SDP can be interrogated to make routing decisions. Can we just be silent about the routing aspects (as we are now) and assume that the media-sensitive routing mentioned in RFC 443 can be extended to "media and language based routing"? Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se --------------AEABD29DF01A6AEA356BD519 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Den 2017-04-27 kl. 05:11, skrev Bernard Aboba:
On Apr 26, 2017, at 14:15, Adam Roach <adam@nostrum.com> wrote:

Given that the direction selected by the WG is to represent language values in SDP, I think this document can *either* say that routing is 100% out of scope and unaddressed, *or* it can add some SIP-level header fields that bear on routing according to human languages. 

[BA] Given that routing work is not in the current WG Charter, my suggestion would be for the current document to say it is out of scope. But it might also say that SIP-level header fields may be defined in future (if only to make it clear that the document is not suggesting SDP-based routing).
The charter is flexible about including routing aspects. It says:
"
 Alternatives such as doing the media
negotiation in SIP have been explored in the past and are out of scope
(although SIP-based mechanisms may be introduced when routing
considerations are addressed).

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

I guess that the work cannot be considered "sufficiently progressed" yet. So we should not deal with routing.
What we can do is to assume that an emergency service or call center application will put the call in an 
appropriate queue just based on SIP fields, and the UAs that have language capabilities matching the indications
will answer. 
However, I do not see how we can have a UA deciding if it has the best match among available UAs so that 
it shall decide to answer the call.

Section 9.2 of RFC 6443 says: " To enable media-sensitive routing,
   the call should include a Session Description Protocol (SDP) offer
   [RFC3264]."
So, there is an assumption that SDP can be interrogated to make routing decisions. 

Can we just be silent about the routing aspects (as we are now) and assume that the
 media-sensitive routing mentioned in RFC 443 can be extended to "media and language based routing"?

Gunnar







-- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se
--------------AEABD29DF01A6AEA356BD519-- From nobody Thu Apr 27 08:20:23 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA294129AAD for ; Thu, 27 Apr 2017 08:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXQeziA9ipb8 for ; Thu, 27 Apr 2017 08:20:16 -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 63DF0129AD2 for ; Thu, 27 Apr 2017 08:19:25 -0700 (PDT) X-Halon-ID: e3427082-2b5c-11e7-b152-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 17:19:19 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <2c2a6785-38e0-64df-753f-dd461108af08@omnitor.se> Date: Thu, 27 Apr 2017 17:19:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------874BE354808375F3C3623CD6" Archived-At: Subject: Re: [Slim] Issue #27 on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:20:21 -0000 This is a multi-part message in MIME format. --------------874BE354808375F3C3623CD6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The text in draft version -08 related to issue #27 has changed a lot since the version commented in LC. It is currently: "5.4. Undefined Combinations With the exception of the case mentioned in Section 5.2 (a spoken language tag for a video stream in parallel with an audio stream with the same spoken language tag), the behavior when specifying a spoken/ written language tag for a video media stream, or a signed language tag for an audio or text media stream, is not defined." The referenced part of section 5.2 says: " Note that while signed language tags are used with a video stream to indicate sign language, a spoken language tag for a video stream in parallel with an audio stream with the same spoken language tag indicates a request for a supplemental video stream to see the speaker." I think that is close to what we want. But we need to have decisions on if it is exactly what we want. Points for decision: 1. Can we use the term "a spoken/written language tag" in 5.4? Addison Phillips did not like our use of that term in another paragraph, now reworded. I suggest to replace it with "a language tag used for a spoken or written language" and hope that is easier to accept. However with my solution proposal for point 3 below, this problem disappears. 2. Are we satisfied with the solution that we cannot indicate use of text captions embedded in the video stream? It was long ago that I saw conversational products placing the text captions or text dialogue overlayed in the video stream. It is still in heavy use for streaming. So, if we do not believe that our specification will be used for streaming services, I think we are satisfied with the current limitation. We had a proposal to always use the -Zxxx script subtag when we mean spoken modality, and usually no script subtag (or a specific script subtag when motivated for the languag when we mean a written modality, but there were some reluctance to that use of the -Zxxx script subtag for this purpose. I suggest that we are happy with the current limitation, but want to hear others' views. 3. Are we satisfied with the limitation described in the section 5.2 citation, requiring a spoken language tag used for the video stream to mean a view of a speaking person only if an audio stream has the same language tag assigned. I think that limitation is not needed and complicates the use. Conclusion: With my proposed resolutions on these points, we should change the two paragraphs cited above to: "5.4. Undefined Combinations The behavior when specifying a language tag for a written language for a video media stream, or a signed language tag for an audio or text media stream, is not defined." The referenced part of section is then proposed to be: " Note that while signed language tags are used with a video stream to indicate sign language, a spoken language tag for a video stream indicates the view of a speaking person in the video stream." If other than my proposals on the points are decided, the wording needs to be adjusted accordingly. /Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------874BE354808375F3C3623CD6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

The text in draft version -08 related to issue #27 has changed a lot since the version commented in LC.

It is currently:

"5.4.  Undefined Combinations

   With the exception of the case mentioned in Section 5.2 (a spoken
   language tag for a video stream in parallel with an audio stream with
   the same spoken language tag), the behavior when specifying a spoken/
   written language tag for a video media stream, or a signed language
   tag for an audio or text media stream, is not defined."

The referenced part of section 5.2 says:

"   Note that while signed language tags are used with a video stream to
   indicate sign language, a spoken language tag for a video stream in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker."

I think that is close to what we want. But we need to have decisions on if it is exactly what we want.

Points for decision:

1. Can we use the term "a spoken/written language tag" in 5.4? Addison Phillips did not like our use of that term in another paragraph, now reworded. I suggest to replace it with "a language tag used for a spoken or written language" and hope that is easier to accept.  However with my solution proposal for point 3 below, this problem disappears.

2. Are we satisfied with the solution that we cannot indicate use of text captions embedded in the video stream? It was long ago that I saw conversational products placing the text captions or text dialogue overlayed in the video stream. It is still in heavy use for streaming. So, if we do not believe that our specification will be used for streaming services, I think we are satisfied with the current limitation.  We had a proposal to always use the -Zxxx script subtag when we mean spoken modality, and usually no script subtag (or a specific script subtag when motivated for the languag when we mean a written modality, but there were some reluctance to that use of the -Zxxx script subtag for this purpose.
I suggest that we are happy with the current limitation, but want to hear others' views.

3. Are we satisfied with the limitation described in the section 5.2 citation, requiring a spoken language tag used for the video stream to mean a view of a speaking person only if an audio stream has the same language tag assigned. I think that limitation is not needed and complicates the use.  


Conclusion:

With my proposed resolutions on these points, we should change the two paragraphs cited above to:

"5.4.  Undefined Combinations

   The behavior when specifying a language tag for a written language for
   a video media stream, or a signed language tag for an audio or text media
   stream, is not defined."

The referenced part of section is then proposed to be:

"   Note that while signed language tags are used with a video stream to
   indicate sign language, a spoken language tag for a video stream
   indicates the view of a speaking person in the video stream."


If other than my proposals on the points are decided, the wording needs to be adjusted accordingly.

/Gunnar




Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------874BE354808375F3C3623CD6-- From nobody Thu Apr 27 13:56:19 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A4212943D for ; Thu, 27 Apr 2017 13:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqUHlktD8yOz for ; Thu, 27 Apr 2017 13:56:14 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5E4129AEB for ; Thu, 27 Apr 2017 13:52:44 -0700 (PDT) X-Halon-ID: 73740336-2b8b-11e7-b152-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 22:52:37 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <681c6809-0703-acb2-d03a-400e001b5a3a@omnitor.se> Date: Thu, 27 Apr 2017 22:52:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------89823CD044B0241A86EB8CF1" Archived-At: Subject: Re: [Slim] Open Issue #28 on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 20:56:18 -0000 This is a multi-part message in MIME format. --------------89823CD044B0241A86EB8CF1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit When dealing with issue #28, making the examples more explicit, we should also deal with why the example with spoken two-way Spanish, Basque and English was understood as if pairing was supported in the message with subject "[Slim] [IANA #949701] expert review". It is not. I guess that the misunderstanding comes from the wording before the example saying in version -08 : " An offer requesting spoken Spanish both ways (most preferred), spoken Basque both ways (second preference), or spoken English both ways (third preference). The offer further requests that the call proceed even if the callee does not support any of the languages: m=audio 49250 RTP/AVP 20 a=hlang-send:es* a=hlang-recv:es* a=hlang-send:eu* a=hlang-recv:eu* a=hlang-send:en* a=hlang-recv:en* " I assume that it is the language from the draft, using the terms "both ways ( x preference)" that causes an impression that the attributes are paired by the preference indications. In practice they will be, but there is nothing in our syntax that says that adjacent lines with different directions indicate pairing, and also nothing that says that indications on the same priority level are paired. Maybe it will be more clear with the following rewording: "An offer requesting sending of spoken Spanish , spoken Basque , or spoken English with preference in this order, and reception of spoken Spanish , spoken Basque , or spoken English also with preference in this order. The offer further requests that the call proceed even if the callee does not support any of the languages:" Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------89823CD044B0241A86EB8CF1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

When dealing with issue #28, making the examples more explicit, we should also deal with why the example with spoken two-way Spanish, Basque and English was understood as if pairing was supported in the message with subject "[Slim] [IANA #949701] expert review". It is not. I guess that the misunderstanding comes from the wording before the example saying in version -08 :

" An offer requesting spoken Spanish both ways (most preferred), spoken
   Basque both ways (second preference), or spoken English both ways
   (third preference).  The offer further requests that the call proceed
   even if the callee does not support any of the languages:

      m=audio 49250 RTP/AVP 20
      a=hlang-send:es*
      a=hlang-recv:es*
      a=hlang-send:eu*
      a=hlang-recv:eu*
      a=hlang-send:en*
      a=hlang-recv:en*
" 

I assume that it is the language from the draft, using the terms "both ways ( x preference)" that causes an impression that the attributes are paired by the preference indications. In practice they will be, but there is nothing in our syntax that says that adjacent lines with different directions indicate pairing, and also nothing that says that indications on the same priority level are paired.

Maybe it will be more clear with the following rewording:

"An offer requesting sending of spoken Spanish , spoken
   Basque , or spoken English with preference in this order, and reception of spoken Spanish , spoken
   Basque , or spoken English also with preference in this order.  The offer further requests that the call proceed
   even if the callee does not support any of the languages:"


Gunnar





Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------89823CD044B0241A86EB8CF1-- From nobody Thu Apr 27 14:22:02 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D14129BD5 for ; Thu, 27 Apr 2017 14:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX0fEwIRkXFO for ; Thu, 27 Apr 2017 14:21:57 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EDB129BF2 for ; Thu, 27 Apr 2017 14:18:10 -0700 (PDT) X-Halon-ID: 027a8b26-2b8f-11e7-b152-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 23:18:07 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 27 Apr 2017 23:18:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C0391700034266DC59B4488F" Archived-At: Subject: Re: [Slim] Open Issue #32 on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:22:00 -0000 This is a multi-part message in MIME format. --------------C0391700034266DC59B4488F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I noticed that the introduction of issue #32 introduces a definition of pairing. Pairing is one of the two functions we lack and I have said that it needs to be added in the current draft or as an extension. But exactly the kind of pairing discussed in issue #32 covers only the combination of speech and a view of the speaker by having exactly the same language tag in audio and video, and I just said in a comment to the related issue #27 that the complexity introduced by that pairing rule was too high and not needed. If it had been a generally useful rule for pairing, I would gladly have accepted it. But other cases of pairing that we eventually need to describe are e.g. a spoken language and a written language, for use as captions to the spoken language. Without pairing, they would be alternatives that can be used separately, and that can be the case even with exactly the same language tag for these two media. Video and text would also be of interest to pair for getting text translations for sign language, or captions for speech. So, I suggest that that part of #32 is not accepted, expecting a more general way of specifying pairing. ( that can be proposed when we have a solution for issue #39). Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------C0391700034266DC59B4488F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I noticed that the introduction of issue #32 introduces a definition of pairing.

Pairing is one of the two functions we lack and I have said that it needs to be added in the current draft or as an extension.

But exactly the kind of pairing discussed in issue #32 covers only the combination of speech and a view of the speaker by having exactly the same language tag in audio and video, and I just said in a comment to the related issue #27 that the complexity introduced by that pairing rule was too high and not needed.

If it had been a generally useful rule for pairing, I would gladly have accepted it.  But other cases of pairing that we  eventually need to describe are e.g. a spoken language and a written language, for use as captions to the spoken language. Without pairing, they would be alternatives that can be used separately, and that can be the case even with exactly the same language tag for these two media.

Video and text would also be of interest to pair for getting text translations for sign language, or captions for speech.

So, I suggest that that part of #32 is not accepted, expecting a more general way of specifying pairing. ( that can be proposed when we have a solution for issue #39).

Gunnar 



Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------C0391700034266DC59B4488F-- From nobody Thu Apr 27 14:34:59 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EBA12960D for ; Thu, 27 Apr 2017 14:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XasoBUgzIlHs for ; Thu, 27 Apr 2017 14:34:54 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E9F129514 for ; Thu, 27 Apr 2017 14:31:42 -0700 (PDT) X-Halon-ID: e4f654c5-2b90-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 23:31:37 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 27 Apr 2017 23:31:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------11D7BA3A454AFE717EB9DE93" Archived-At: Subject: Re: [Slim] Open Issue #34 on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:34:57 -0000 This is a multi-part message in MIME format. --------------11D7BA3A454AFE717EB9DE93 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I agree that the Accept-Language syntax is good with all language tags for one media and direction is collected in one attribute. Also including the q-value. I suggest that we go this way. That would also satisfy issue #39. The use of the q-values enable a simple definition of pairing and relative priority between languages in different media, saying that pairing is indicated by setting exactly the same q-value for two languages in the same direction but different media. One required and one complementary language in different media but the same direction can be indicated by the q-values being less than 0.1 apart. True alternatives in different media but the same direction can be indicated by th q-values being 0.1 or more apart. That can be introduced i an extension or from the beginning. /Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------11D7BA3A454AFE717EB9DE93 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I agree that the Accept-Language syntax is good with all language tags for one media and direction is collected in one attribute. Also including the q-value. I suggest that we go this way.

That would also satisfy issue #39.

The use of the q-values enable a simple definition of pairing and relative priority between languages in different media, saying that pairing is indicated by setting exactly the same q-value for two languages in the same direction but different media.

One required and one complementary language in different media but the same direction can be indicated by the q-values being less than 0.1 apart.

True alternatives in different media but the same direction can be indicated by th q-values being 0.1 or more apart.

That can be introduced i an extension or from the beginning.

/Gunnar



Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------11D7BA3A454AFE717EB9DE93-- From nobody Thu Apr 27 14:47:47 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2EB129458 for ; Thu, 27 Apr 2017 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMZwbDZ-0HIq for ; Thu, 27 Apr 2017 14:47:43 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C521200DF for ; Thu, 27 Apr 2017 14:44:28 -0700 (PDT) X-Halon-ID: ae79618b-2b92-11e7-bca7-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 23:44:24 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <0f52e454-4c13-5525-9cb5-2b66774f17b0@omnitor.se> Date: Thu, 27 Apr 2017 23:44:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------12A2AB1DBDABC2C9A9C5E520" Archived-At: Subject: Re: [Slim] Open Issue #35 on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:47:46 -0000 This is a multi-part message in MIME format. --------------12A2AB1DBDABC2C9A9C5E520 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I exect that the abbreviation in issue #35 will be popular and support its addition. However, all aspects of the indication must be equal in both directions to be used. So, when pairing and relative preference between modalities are introduced, either initially or as an extension, then this short form cannot be used for situations when pairing or relative preference is intended to be used in one direction or in different ways in different directions. And that is the most likely way of using pairing and relative preference between modalities. Wording needs to be checked that it will allow and prepare for the extension. Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------12A2AB1DBDABC2C9A9C5E520 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I exect that the abbreviation in issue #35 will be popular and support its addition.

However, all aspects of the indication must be equal in both directions to be used. So, when pairing and relative preference between modalities are introduced, either initially or as an extension, then this short form cannot be used for situations when pairing or relative preference is intended to be used in one direction or in different ways in different directions. And that is the most likely way of using pairing and relative preference between modalities.

Wording needs to be checked that it will allow and prepare for the extension.

Gunnar

Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------12A2AB1DBDABC2C9A9C5E520-- From nobody Thu Apr 27 15:02:05 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE6F129B3A for ; Thu, 27 Apr 2017 15:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gc2-9K0JWT4 for ; Thu, 27 Apr 2017 15:02:01 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D7812949B for ; Thu, 27 Apr 2017 14:58:58 -0700 (PDT) X-Halon-ID: b50edfbd-2b94-11e7-b152-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 27 Apr 2017 23:58:53 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 27 Apr 2017 23:58:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D18B80992A23D47DC3E50C9B" Archived-At: Subject: Re: [Slim] Open Issue #26 on draft-ietf-slim-negotiating-human-language X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:02:04 -0000 This is a multi-part message in MIME format. --------------D18B80992A23D47DC3E50C9B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I agree that #26 is a sufficient method to add a relative preference between languages in different modalities. But it does not cover pairing that would e.g. be needed for captioning text to speech. So, only if #34 can not be decided to be used with my proposed additions for pairing and relative preference, #26 should be accepted. Gunnar Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------D18B80992A23D47DC3E50C9B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I agree that #26 is a sufficient method to add a relative preference between languages in different modalities. But it does not cover pairing that would e.g. be needed for captioning text to speech.

So, only if #34 can not be decided to be used with my proposed additions for pairing and relative preference, #26 should be accepted.

Gunnar

Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------D18B80992A23D47DC3E50C9B-- From nobody Fri Apr 28 03:10:27 2017 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FA5129BBE for ; Fri, 28 Apr 2017 03:10:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZn0W-yqcgG7 for ; Fri, 28 Apr 2017 03:10:21 -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 A2B8D12E856 for ; Fri, 28 Apr 2017 03:07:25 -0700 (PDT) X-Halon-ID: 76d3f9b6-2bfa-11e7-9f7f-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [77.53.231.21]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 28 Apr 2017 12:07:19 +0200 (CEST) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 28 Apr 2017 12:07:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------02F7FB7D42C82AFEB0DA8645" Archived-At: Subject: Re: [Slim] Open Issue #26 on draft-ietf-slim-negotiating-human-language and also #27, #34 and #39 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 10:10:26 -0000 This is a multi-part message in MIME format. --------------02F7FB7D42C82AFEB0DA8645 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Issue #26 started as a discussion of functionality extensions. That topic also relate to issues #34 and #39. Because the coding depends on the selection of resolution on these issues. Bernard also brought up the need for coding of indications of captioning that is simultaneous use of languages in https://www.ietf.org/mail-archive/web/slim/current/msg00730.html. It could have been assigned a separate issue but I include discussion of that need here. When resolving the current list of issues with draft-ietf-slim-negotiating-human-language we need to see how the two discussed functionlity extensions can be coded. The extensions are: a) relative preference between languages in different media and the same direction, and b) indication of simultaneous versus alternative use of languages in the same direction. This is an overview of possible solutions to the functionality extensions and how they depend on the selected solutions of the issues. I have submitted similar proposals before, but this proposal is further limited to the two most suitable proposals. The earlier discussion containing more alternatives are found in https://mailarchive.ietf.org/arch/msg/slim/wR7iFD_gEINQh3RMGRFnj5kzGvA The selected solutions for the functionality extensions can be included in the current draft or specified in a separate draft. If it is specified in a separate draft, the current draft needs to be checked and possibly adjusted so that it allows the selected syntax of the extensions. *A. What we have specified in draft -08 is purely for lanuage alternatives * The current specification is capable of negotiation of one language per media and direction. There is a way to express preference between languages within each media and direction, but no possibility to express preference between languages in the same direction in different media. There is freedom to use more than one media simultaneously if so decided but no indication if that is preferred. *B. Indication of preference between media.* There is a need to be able to indicate which of a set of language/media indications are more preferred alternatives than others. Examples: 1. A user A want to get written English in text, A can as a less preferred alternative accept to get spoken English. An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call. Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users. 2. A user A prefer to receive spoken language, and can accept to receive text. When answering party B can use spoken language, that will be satisfied, otherwise written language will be used. 3. A user A prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language. 4. A user A prefer to use sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text. 5. A user A prefer to send sign language and receive text (deaf-blind user) and can accept to send text. In a call with a person with similar preferences, text will be used both ways, otherwise sign one way and text the other. *Alternative coding proposals* B.1 Based on draft -08, add the coding of an asterisk last in an attribute to mean lower preference for a lanugage/media combination than the one(s) without an asterisk. example where audio and text are alternatives and text preferred m=audio a=hlang-recv:en* m=text a=hlang-recv:en The asterisk is already specified to be used as an indication that the call should not be denied if language preferences cannot be met, but there is no rule for which attribute to put the asterisk for that purpose. This additional use of the asterisk brings a motivation to keeping the asterisk as a parameter on media level. There is slight, but manageable interaction between the two usages of the asterisk that needs to be expplained in the draft. B.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP. The Issue tracker issues #34 and #39 propose to change to a more condensed syntax. Both should be satisfied by using a syntax similar to the Accept-Language. If that route is taken, it opens for a quite clean way to add indication of relative preference between languages in different media. Example where sign language is higher preferred than text. m=video 51372 RTP/AVP 31 32 a=hlang-recv:ase;q=0.9 a=hlang-send:ase;q=0.9 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.5,*;q=0.1 a=hlang-recv:en;q=0.5 Note that the asterisk is used here only with its original meaning as indication that the call should not be denied if languages can not be matched. *C. **Indication of simultanous versus alternative languages.* A way is required to indicate use of captioning and other situations where use of simultaneous languages in different modalities are preferred: 1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) . This can be provided automatically in some settings, but also traditionally by a manned service. The written language may be the same as the spoken, or another language. 2. Preference for hearing spoken language and simultaneously seeing the speaker in video. (lip-reading). Easily and naturally provided once the need is known. 3. Preference for seeing sign language and simultaneously hear spoken language in audio. ( for multiple users at the terminal, or for hearing persons with some limited knowledge in the specified sign language ) One of the streams is provided by an interpreter. 4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video.) Some of these can be acceptable also if just one of the language/media combinations can be provided, but is much more preferred if both can be provided together. In other cases it is essential to get both simultaneously. There is a need to be able to indicate this preference for getting the languages together. *Alternative coding proposals:* C.1 Use the -t- subtag for transformed content on a language indication defined in RFC 6497 as an indication that this language can be provided or is desired together with a language in another modality. Use this indication together with solution B.1 Example: Indicate that written English and spoken English are desired together and written English expected to be transformed. but the call shall not be denied if that combination is not possible, and then written English is preferred. m=text a=hlang-recv:en-t-en m=audio a=hlang-recv:en* The -t- indicated with the -recv direction shall not be understood that the indicated language needs to be transformed. It is just an expectation that enables it to express that the languages should be provided simultaneously. C.2. Use the Accept-Language syntax for the hlang attributes and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives. Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied. m=audio 51372 RTP/AVP 0 a=hlang-recv:ase;q=0.5 a=hlang-send:ase;q=0.5 m=text 49250 RTP/AVP 98,99 a=hlang-send:en;q=0.51 a=hlang-recv:en;q=0.51,*;q=0.1 The q-values differences are within 0.1 so it indicates a preference for getting both together, but if that is not possible, text is preferred. *Judgement of the alternatives:* I have a preference for solutions B.2 and C.2 because they are logically most clean. They require that we accept the proposals in Issues #34 and #39 to move to the Accept-Language syntax. B.1 and C.1 are easily added to the syntax of the current draft and have sufficient functionality for most cases. There will be some limitations. B.1 helps to motivate to keep the * parameter on media level. The use of the -t- language subtag in B.2 may need discussion with language coding experts. Summary: I suggest to accept the proposal in #34, and use the coding B.2 and C.2 above for the functionality extensions. That would mean that the use of the asterisk is only for non-denial indication. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 Den 2017-04-25 kl. 20:25, skrev Bernard Aboba: > Currently 10 Issues remain open from IETF Last Call: > https://trac.ietf.org/trac/slim/report/1 > > These include: > Ticket > > Summary > > Component > > Version > > Milestone > > Type > > Owner > > Status > > Created > > #27 The cases in the > "Silly states" section 5.4 are not all silly. > > negotiating-human-language 2.0 milestone1 > defect > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #19 Use Media Type > registration template > multilangcontent > > enhancement rfc.nik.tomkinson@gmail.com > assigned Aug 17, 2016 > #28 Examples section 5.5 > requires expansion > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #32 Audio/Video > Coordination > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org new > Mar 22, 2017 > #34 Use the > Accept-Language syntax > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #35 Have an attribute to > abbreviate the bidirectionally-symmetric case > > negotiating-human-language 2.0 milestone1 > defect > rg+ietf@randy.pensive.org > assigned Mar 22, 2017 > #38 Routing out of scope > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #39 Syntax Collapse > > negotiating-human-language 1.0 milestone1 > defect > draft-ietf-slim-negotiating-human-language@ietf.org > new Apr > 25, 2017 > #26 Make use of the > asterisk modifier on media level with session scope also for media > level purposes > negotiating-human-language 2.0 milestone1 > enhancement > gunnar.hellstrom@omnitor.se new > Mar 22, 2017 > #29 Include more fields > for attribute registration from 4566bis > > > > > _______________________________________________ > 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 --------------02F7FB7D42C82AFEB0DA8645 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Issue #26 started as a discussion of functionality extensions. That topic also relate to issues #34 and #39. Because the coding depends on the selection of resolution on these issues.

Bernard also brought up the need for coding of indications of captioning that is simultaneous use of languages  in https://www.ietf.org/mail-archive/web/slim/current/msg00730.html. It could have been assigned a separate issue but I include discussion of that need here.

When resolving the current list of issues with draft-ietf-slim-negotiating-human-language we need to see how the two discussed functionlity extensions can be coded. The extensions are: a) relative preference between languages in different media and the same direction, and b) indication of simultaneous versus alternative use of languages in the same direction.

This is an overview of possible solutions to the functionality extensions and how they depend on the selected solutions of the issues. I have submitted similar proposals before, but this proposal is further limited to the two most suitable proposals. The earlier discussion containing more alternatives are found in https://mailarchive.ietf.org/arch/msg/slim/wR7iFD_gEINQh3RMGRFnj5kzGvA

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

A. What we have specified in draft -08 is purely for lanuage  alternatives

The current specification is capable of negotiation of one language per media and direction. There is a way to express preference between languages within each media and direction, but no possibility to express preference between languages in the same direction in different media. There is freedom to use more than one media simultaneously if so decided but no indication if that is preferred.

B. Indication of preference between media.

There is a need to be able to indicate which of a set of language/media indications are more preferred alternatives than others.

Examples:

1. A user A want to get written English in text, A can as a less preferred alternative accept to get spoken English.  An answering party B who can use text will then respond with written text and get good satisfaction, while another answering user C without text capability will answer in spoken English and have a possibility for a reasonably successful call.
Without this indication, the first answering party B may have seen the spoken and written alternatives as true equal preference alternatives and answered with spoken English that will result in less satisfied users.

2. A user A prefer to receive spoken language, and can accept to receive text.   When answering party B can use spoken language, that will be satisfied, otherwise written language will be used.

3. A user A prefer to use spoken language in both directions, and can accept to use sign language in video in both directions. Answering party B has a clear indication of why both signed and written is indicated and can answer according to its capabilities trying to satisfy the preference for spoken language.

4. A user A prefer to use  sign language in both directions and can accept to use written language in both directions. Sign language users will use sign language, others will use text.

5. A user A prefer to send sign language and receive text (deaf-blind user) and can accept to send text.  In a call with a person with similar preferences, text will be used both ways, otherwise sign one way and text the other.

Alternative coding proposals

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

The asterisk is already specified to be used as an indication that the call should not be denied if language preferences cannot be met, but there is no rule for which attribute to put the asterisk for that purpose. This additional use of the asterisk brings a motivation to keeping the asterisk as a parameter on media level. There is slight, but manageable interaction between the two usages of the asterisk that needs to be expplained in the draft.

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

The Issue tracker issues #34 and #39 propose to change to a more condensed syntax. Both should be satisfied by using a syntax similar to the Accept-Language. If that route is taken, it opens for a quite clean way to add indication of relative preference between languages in different media.  

Example where sign language is higher preferred than text.

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


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

Note that the asterisk is used here only with its original meaning as indication that the call 
should not be denied if languages can not be matched.

C. Indication of simultanous versus alternative languages.

A way is required to indicate use of captioning and other situations where use of simultaneous languages in different modalities are preferred:

1. Preference for hearing spoken language and simultaneously read written language in text. ( captioning) .   This can be provided automatically in some settings, but also traditionally by a manned service. The written language may be the same as the spoken, or another language.

2. Preference for hearing spoken language and simultaneously seeing the speaker in video.   (lip-reading).  Easily and naturally provided once the need is known.

3. Preference for seeing sign language and simultaneously hear spoken language in audio.  ( for multiple users at the terminal, or for hearing persons with some limited knowledge in the specified sign language )    One of the streams is provided by an interpreter.

4. Preference for hearing spoken language and simultaneously view written language in video. (captioning if we accept to specify text as overlay on video.)

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

Alternative coding proposals:

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

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

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

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

C.2. Use the Accept-Language syntax for the hlang attributes and add the usage rules that q-values with less than .1 difference mean languages with a preference to be used together. Higher differences indicate that they are alternatives.  Thereby it is both possible to indicate simultaneity and preference if the simultaneity cannot be satisfied. 
 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5


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

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

Judgement of the alternatives:
I have a preference for solutions B.2 and C.2 because they are logically most clean. They require that we accept the proposals in Issues #34 and #39 to move to the Accept-Language syntax.

B.1 and C.1 are easily added to the syntax of the current draft and have sufficient functionality for most cases. There will be some limitations. B.1 helps to motivate to keep the * parameter on media level. The use of the -t-  language subtag in B.2 may need discussion with language coding experts.

Summary:  I suggest to accept the proposal in #34, and use the coding B.2 and C.2 above for the functionality extensions. That would mean that the use of the asterisk is only for non-denial indication.


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

Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
Currently 10 Issues remain open from IETF Last Call:

These include: 
Ticket Summary Component Version Milestone Type Owner Status Created
#27 The cases in the "Silly states" section 5.4 are not all silly. negotiating-human-language 2.0 milestone1 defect gunnar.hellstrom@omnitor.se new Mar 22, 2017
#19 Use Media Type registration template multilangcontent

enhancement rfc.nik.tomkinson@gmail.com assigned Aug 17, 2016
#28 Examples section 5.5 requires expansion negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#32 Audio/Video Coordination negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org new Mar 22, 2017
#34 Use the Accept-Language syntax negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#35 Have an attribute to abbreviate the bidirectionally-symmetric case negotiating-human-language 2.0 milestone1 defect rg+ietf@randy.pensive.org assigned Mar 22, 2017
#38 Routing out of scope negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#39 Syntax Collapse negotiating-human-language 1.0 milestone1 defect draft-ietf-slim-negotiating-human-language@ietf.org new Apr 25, 2017
#26 Make use of the asterisk modifier on media level with session scope also for media level purposes negotiating-human-language 2.0 milestone1 enhancement gunnar.hellstrom@omnitor.se new Mar 22, 2017
#29 Include more fields for attribute registration from 4566bis 


_______________________________________________
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
--------------02F7FB7D42C82AFEB0DA8645--