Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.txt

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 30 June 2017 13:37 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 9EB87129B1D for <slim@ietfa.amsl.com>; Fri, 30 Jun 2017 06:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSlCxMfJlSHm for <slim@ietfa.amsl.com>; Fri, 30 Jun 2017 06:37:49 -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 303AD129AB7 for <slim@ietf.org>; Fri, 30 Jun 2017 06:37:49 -0700 (PDT)
X-Halon-ID: 4b1615a0-5d99-11e7-8604-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.36.99]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 4b1615a0-5d99-11e7-8604-0050569116f7; Fri, 30 Jun 2017 15:37:43 +0200 (CEST)
To: Randall Gellens <rg+ietf@randy.pensive.org>, slim@ietf.org
References: <149826161364.7680.4546115441019121579@ietfa.amsl.com> <8cbb2083-b02f-20eb-ab7f-a03c85cb95f8@omnitor.se> <p06240608d57b579cec3d@[192.168.1.189]> <9c7041be-06ea-106c-90f8-14e2ae4f6abd@omnitor.se> <p06240601d57bff4081b4@[50.95.104.251]>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <9f1a7c5b-09df-0584-6dc6-7be07cc8fa4f@omnitor.se>
Date: Fri, 30 Jun 2017 15:37:41 +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: <p06240601d57bff4081b4@[50.95.104.251]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/9WZrsR5x4ju3mIeYT0U0PQDOZQ0>
Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-11.txt
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jun 2017 13:37:52 -0000


Den 2017-06-30 kl. 15:15, skrev Randall Gellens:
> At 8:09 AM +0200 6/30/17, Gunnar Hellström wrote:
>
>>  Randall,
>>  All your resolutions are fine except for Issue 2. See explanation 
>> below.
>
> OK, new wording:
>
>    Note that separate work may introduce additional information
>    regarding language/modality preferences among media.
Fine.
>
> Note that there is no longer a reference to the draft.
Yes, since there are currently two drafts with competing solutions, I 
think it is better to not reference them.

The new drafts have been available for 18 days now, and I have not got 
any substantial feedback. That is not promising for the progress, and 
not what I expected when I accepted to make separate drafts for the 
functionality that will add substantial usability to 
draft-ietf-slim-negotiating-human-language.


>
>>
>>  Den 2017-06-30 kl. 05:15, skrev Randall Gellens:
>>>  At 11:30 AM +0200 6/26/17, Gunnar Hellström wrote:
>>>
>>>>   Good to see progress.
>>>>
>>>>   I checked the numbered change proposals I submitted earlier under 
>>>> subject " I-D Action: 
>>>> draft-ietf-slim-negotiating-human-language-10.txt" and found that 
>>>> most of them were solved or agreed to be ignored. Only proposal 2.2 
>>>> was not acted on, so I repeat it here together with a few new 
>>>> findings:
>>>>
>>>>   -----Issue 1, old 2.2 The attributes can appear in both offers 
>>>> and answers -----------
>>>>   -------Old text 2.2 at end of first paragraph of 5.2---------
>>>>
>>>>
>>>>   Each can appear in an offer for a media
>>>>   stream.
>>>>   --New text 2.2---
>>>>   Each can appear in an offer and answer for a media
>>>>   stream.
>>>>   ---Reasoning:----------
>>>>
>>>>   This paragraph is an introduction to the attributes. It should 
>>>> mention the full use, in both offer and answer. The following 
>>>> paragraphs tell about specifics for offer vs answer.
>>>>   --End of change 2.2---
>>>>
>>>>   ---End of Issue 1----------
>>>
>>>  Yes, I agree.
>>>
>>>>
>>>>   ------Issue 2 , reduce info on possible extensions to not be 
>>>> solution specific----------
>>>>
>>>>   In section 5.2, middle:
>>>>
>>>>   -----Old text------------
>>>>
>>>>     See Section 5.3 for more
>>>>      information and discussion.  Note that separate work
>>>>      [I-D.hellstrom-slim-modalitypref] extends the use of the 
>>>> asterisk to
>>>>      convey additional information regarding language/modality 
>>>> preferences
>>>>      among media.
>>>>
>>>>   -----New text proposal for Issue 2-----------
>>>>
>>>>       See Section 5.3 for more information and discussion.
>>>>   <paragraph separator>
>>>>      Note that separate work may introduce additional information 
>>>> regarding language/modality
>>>>      preferences among media.
>>>>
>>>>   ---Reasoning: ---------
>>>>   Two ways to convey language/modality preferences among media have 
>>>> been proposed, one based on the asterisk 
>>>> (draft-hellstrom-slim-modalitypref), and another based on the SDP 
>>>> gouping framework (draft-hellstrom-language-grouping). There are 
>>>> drafts for both. The clean one seems to be the method based on SDP 
>>>> grouping. It has no known interoperability problems.
>>>>    The proposed wording of the note (as a separate paragraph) is 
>>>> intended to cover both methods, but has less effect as a warning 
>>>> against interoperabitlity problems caused by the asterisk based 
>>>> solution.
>>>>
>>>>   A decision is needed for which alternative to continue with, I 
>>>> prefer the one based on SDP grouping.
>>>>
>>>>
>>>>
>>>>   -----End of issue 2-----------------------
>>>
>>>  I will go back to my original wording, which I think was specific 
>>> enough to give readers of this document a hint to read yours, and 
>>> general enough to not constrain your document:
>>>
>>>      "uses the asterisk (or lack thereof) to convey additional 
>>> information between endpoints."
>>  I need the whole sentence to understand the proposal. Do you mean:
>>
>>  "Note that separate work [I-D.hellstrom-slim-modalitypref] extends 
>> the use of the asterisk (or lack thereof) to
>>     convey additional information between endpoints."
>>
>>  Or did you mean:
>>
>>   "Note that separate work extends the use of the asterisk (or lack 
>> thereof) to
>>     convey additional information between endpoints."
>>
>>  Anyway, both are currently wrong. I have submitted two alternative 
>> drafts for the modality preference indication, one adding meaning to 
>> the asterisk (draft-hellstrom-slim-modalitypref) and the other using 
>> SDP grouping instead, not touching the asterisk 
>> (draft-hellstrom-language-grouping). I prefer the SDP grouping 
>> proposal, but want to hear others' views.  When we have a decision, I 
>> will let one of them expire and we can sharpen up the note if the 
>> draft is still open for modifications.
>>
>>  So, at the moment, it is only my proposed wording in a separate note 
>> as shown above in issue 2 that works.
>>
>>
>>
>>>
>>>>
>>>>   ------Issue 3 - typo in 5.5------------
>>>>
>>>>   Typo in section 5.5, at the end of page 9
>>>>
>>>>   -------old text-----
>>>>   An offer of answer
>>>>   -----new text----
>>>>
>>>>      An offer or answer
>>>>   -----end of issue 3------
>>>
>>>  Thanks.
>>>
>>>>
>>>>   ----Issue 4  allow asterisks also in answers, but do not assign a 
>>>> meaning---------
>>>>   The second example in 5.5 has asterisks last in the attributes 
>>>> and says that the example can be either an offer or an answer.
>>>
>>>  That's an error, thanks for catching it.  It should say "an offer".
>>>
>>>>
>>>>   But section 5.2, fourth paragraph currently only says that the 
>>>> asterisk can appear in an offer.
>>>
>>>  It doesn't prohibit an asterisk in an answer, but it only defines 
>>> the meaning of an asterisk in an offer.  I suggest we leave it this 
>>> way. Your draft can then define the meaning of an asterisk in an 
>>> offer.  Note that the ABNF defining the syntax does not 
>>> differentiate between an offer and an answer, hence, an asterisk is 
>>> technically permitted in an answer.  For clarity, I will add to 5.2:
>>>
>>>      An asterisk appended to any value in any media in an answer is 
>>> undefined.
>>>
>>>>
>>>>   I suggest to amend this by allowing the asterisk to appear in an 
>>>> answer, but not assign any meaning to it.
>>>>   This is more future proof and may make implementation of the 
>>>> answering part easier than keeping the currect restriction.
>>>>
>>>>   ------New paragraph after paragraph four in 5.2-------
>>>>   The asterisk token MAY also be appended last in a 'hlang' 
>>>> attribute in an answer, but this specification does not define any 
>>>> meaning to an asterisk in that position.
>>>>   ------End of proposal for Issue 4...........
>>>>   -----End of Issue 4----------------
>>>>    ----Issue 5 correct SDP syntax in answer example on page 10 
>>>> -------------------
>>>>   In the answer example in section 5.5 on page 10, the answer shows 
>>>> no video m-line. There was an m-lne for video in the offer, then 
>>>> one must be included in the aswer.
>>>>
>>>>   ---old text in 5.5----
>>>>      An answer for the above offer, indicating text in which the 
>>>> callee
>>>>      will receive written Spanish, and audio in which the callee 
>>>> will send
>>>>      spoken Spanish:
>>>>
>>>>         m=text 45020 RTP/AVP 103 104
>>>>         a=hlang-recv:sp
>>>>
>>>>         m=audio 49250 RTP/AVP 20
>>>>         a=hlang-send:sp
>>>>
>>>>   -------new text-----------
>>>>      An answer for the above offer, indicating text in which the 
>>>> callee
>>>>      will receive written Spanish, and audio in which the callee 
>>>> will send
>>>>      spoken Spanish. The answering party had no video capability:
>>>>
>>>>         m=video 0 RTP/AVP 31 32
>>>>         m=text 45020 RTP/AVP 103 104
>>>>         a=hlang-recv:sp
>>>>
>>>>         m=audio 49250 RTP/AVP 20
>>>>         a=hlang-send:sp
>>>>
>>>>
>>>>   ---------end of proposal------------
>>>>   --------end of Issue 5---------------
>>>
>>>  Thanks.
>>>
>>>>
>>>>   --------Issue 6 - most examples have asterisks on all attributes, 
>>>> reduce number of asterisks -------
>>>>   In section 5.5 Examples, nearly all examples including the use of 
>>>> the asterisk has the asterisk on all attribute lines in the whole 
>>>> SDP, even if it is sufficient to have it on one attribute. I think 
>>>> this might have confused the reviewers and caused some of the 
>>>> thoughts about assumed grouping and linking and wondering about 
>>>> semantic rules around the asterisk that was not intended by the draft.
>>>>   --------Proposed action for Issue 6------------
>>>>   Delete some of the asterisks in the examples in section 5.5, so 
>>>> that only one example has asterisks on all attributes and the 
>>>> others have just one or a varying number of asterisks.
>>>>   --------End of issue 6-----------------------------------
>>>
>>>  OK.
>>>
>>>>
>>>>   --------Issue 7 Missing link to 'hlang-value' in the syntax 
>>>> section 6.1-------------------
>>>>
>>>>   I suggest to insert a line in two places to link the attribute to 
>>>> the 'hlang-value' syntax description, matching the format used in 
>>>> rfc4566bis.
>>>>
>>>>   ------Old text in two places in section 6.1--------
>>>>    Attribute Syntax:
>>>>
>>>>   --------New text in two places in section 6.1-----
>>>>     Value: hlang-value
>>>>     Attribute Syntax:
>>>>
>>>>   ---------End of Issue 7.----------------
>>>
>>>  OK.
>>>
>>  Thanks,
>>  Gunnar
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  gunnar.hellstrom@omnitor.se
>>
>
>
Gunnar

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