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 Hellström <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.
- [Slim] I-D Action: draft-ietf-slim-negotiating-hu… internet-drafts
- Re: [Slim] I-D Action: draft-ietf-slim-negotiatin… Gunnar Hellström
- Re: [Slim] I-D Action: draft-ietf-slim-negotiatin… Randall Gellens
- Re: [Slim] I-D Action: draft-ietf-slim-negotiatin… Gunnar Hellström
- Re: [Slim] I-D Action: draft-ietf-slim-negotiatin… Randall Gellens
- Re: [Slim] I-D Action: draft-ietf-slim-negotiatin… Gunnar Hellström