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

Randall Gellens <rg+ietf@randy.pensive.org> Fri, 30 June 2017 13:15 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 D69501204DA for <slim@ietfa.amsl.com>; Fri, 30 Jun 2017 06:15:24 -0700 (PDT)
X-Quarantine-ID: <ke8U37IVw6IS>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ke8U37IVw6IS for <slim@ietfa.amsl.com>; Fri, 30 Jun 2017 06:15:23 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 08EAF1293E1 for <slim@ietf.org>; Fri, 30 Jun 2017 06:15:23 -0700 (PDT)
Received: from [50.95.104.251] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 30 Jun 2017 06:18:16 -0700
Mime-Version: 1.0
Message-Id: <p06240601d57bff4081b4@[50.95.104.251]>
In-Reply-To: <9c7041be-06ea-106c-90f8-14e2ae4f6abd@omnitor.se>
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>
X-Mailer: Eudora for Mac OS X
Date: Fri, 30 Jun 2017 06:15:19 -0700
To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>, slim@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/FZ49n9O2lV813-LGMTVGexPPTLE>
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:15:25 -0000

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.

Note that there is no longer a reference to the draft.

>
>  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
>  +46 708 204 288


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Please ignore previous fortune.