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

[Gunnar Hellström <[e-mail]>]

Randall,
All your resolutions are fine except for Issue 2. See explanation below.

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
[e-mail]
[phone]