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

[Randall Gellens <[e-mail]>]

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."

>
>  ------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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Invention is the mother of necessity.       --Thorstein Veblen