Re: [Slim] [IANA #949701] expert review for draft-ietf-slim-negotiating-human-language (sdp-parameters)

[Bernard Aboba <[e-mail]>]

Randall Gellens said:

"The WG explicitly decided to take routing out of scope to advance the
simple proposal in the draft."

[BA] While it is correct that the WG decided to leave routing out of scope
for this document, the text does say anything about this, so that even an
expert reader could be confused. Could we add some clarifying text?

Adam Roach said:

"I'll note that much of this can be fixed if the syntax is collapsed"

[BA] I didn't see a reply to Adam's suggestion, which aside from the syntax
issues would address concerns about SDP size.

On Tue, Mar 28, 2017 at 4:54 PM, Randall Gellens <[e-mail]>
wrote:

> At 8:31 PM +0000 3/28/17, Sabrina Tanamal via RT wrote:
>
>  Bernard and Natasha,
>>
>>  We're forwarding this message to you based on our conversation at the
>> IANA Services desk. Please contact Adam Roach and Flemming Andreasen for
>> additional information.
>>  Thank you,
>>
>>  Sabrina
>>
>>  ----
>>
>>  From:  "Adam Roach" <[e-mail]>
>>  CC:    "[e-mail]" <[e-mail]>, "
>> [e-mail]" <[e-mail]>, [e-mail]
>>  To:    [e-mail]
>>  Date:  Tue, 7 Mar 2017 13:03:00 -0600
>>  Subject:       SDPDIR Review: Review of draft-ietf-slim-negotiating-hu
>> man-language-08
>>  Download (untitled)
>>  /
>>  with headers
>>
>>  text/plain 3.9KiB
>>  Authors of draft-ietf-slim-negotiating-human-language --
>>
>>  I have reviewed this document on behalf of the SDP directorate [1].
>>  Please wait for direction from your document shepherd or AD before
>>  posting a new version of the draft.
>>
>>  It is my opinion that the document, as presently written, is too
>>  ambiguous to publish, for the reasons explained below.
>>
>>  Aside -- I have a concern that negotiating language in SDP rather
>>  than SIP makes it necessary for proxies to look into SDP to make
>>  routing decisions, which is a pretty substantial layer violation
>>  (keep in mind, for example, that SIP was originally envisioned to
>>  contain S/MIME encrypted bodies, which would render the SDP
>>  unreadable by proxies). However, I note that section 5.1 indicates
>>  that this has issue been litigated in the working group already, and
>>  that it chose to do things in the way documented in the current draft.
>>
>
> Negotiation in SDP vs SIP was extensively debated for a couple of years,
> and Flemming was part of that discussion.  The WG explicitly decided to
> take routing out of scope to advance the simple proposal in the draft.
>
>
>  Leaving the layering issue aside, I find the proposed syntax to be
>>  confusing and potentially ambiguous. In particular, the draft does not
>>  address what it would mean if an implementation added "*" to the end of
>>  some language attributes, but omitted it from others; and, at the same
>>  time, it does not preclude senders from doing so.
>>
>
> The draft explicitly says that an asterisk need only be appended to any
> attribute value:
>
>    An asterisk appended to any value indicates a
>    request by the caller to not fail the call if there is no language in
>    common.
> ...
>    The mechanism for indicating this preference is that, in an offer, if
>    the last character of any of the 'hlang-recv' or 'hlang-send' values
>    is an asterisk, this indicates a request to not fail the call.  The
>    called party MAY ignore the indication, e.g., for the emergency
>    services use case, regardless of the absence of an asterisk, a PSAP
>    will likely not fail the call; some call centers might reject a call
>    even if the offer contains a language with an asterisk.
>
>
>  Additionally, the descriptive text doesn't have any explanation that
>>  adjacent language tag pairs are somehow related to each other; however,
>>  there is an example whose accompanying text makes a strong implication
>>  that such pairing is intended:
>>
>>  Hide quoted text
>>
>>>  An offer requesting spoken Spanish both ways (most preferred), spoken
>>>  Basque both ways (second preference), or spoken English both ways
>>>  (third preference). The offer further requests that the call proceed
>>>  even if the callee does not support any of the languages:
>>>
>>>  m=audio 49250 RTP/AVP 20
>>>  a=hlang-send:es*
>>>  a=hlang-recv:es*
>>>  a=hlang-send:eu*
>>>  a=hlang-recv:eu*
>>>  a=hlang-send:en*
>>>  a=hlang-recv:en*
>>>
>>
> I'm not following what you mean.  There is no grouping or pairing nor
> restrictions on which languages can be used with which others.  The draft
> presents a simple mechanism to enable basic language negotiation with
> media, it does not attempt to capture the rich complexity of human
> interactions or polylinguism.
>
>
>  Until this example, I would have assumed that an es/en pairing would be
>>  okay here; but the text implies that this would not be allowed. While
>>  en/es isn't necessarily a good example, I'll point out that I've seen a
>>  number of in-person conversations in which one person spoke Norwegian
>>  while the other spoke Swedish, with little apparently difficulty
>> conversing.
>>
>>  The document needs more text that talks about how send and receive
>>  languages are paired (is the example actually correct?), or it needs to
>>  make clear that such pairing is not part of the mechanism. It also needs
>>  clearer rules around use of "*", including specification of the intended
>>  behavior when its presence is inconsistent with a media section.
>>
>>  I'll note that much of this can be fixed if the syntax is collapsed so
>>  that each media section can have at most one hlang-send and one
>>  hlang-receive, each of which contain a list of one or more languages
>>  that can be sent or received. This is also much more consistent with the
>>  way SDP attributes are used in general. The presence of a "*" token on
>>  that line would indicate the "call should happen even without matching
>>  languages" characteristic; since there is only one place to add this
>>  indicator, the ambiguity of some lines indicating it and others not
>>  disappears. The preceding example would collapse to:
>>
>>  m=audio 49250 RTP/AVP 20
>>  a=hlang-send:es eu en *
>>  a=hlang-recv:es eu en *
>>
>>  ...and the example text would be revised to remove the implication that
>>  *sending* "es" necessarily implies *receiving* "es".
>>
>>  I'll further note that the majority of SDP libraries I've worked with
>>  would make accessing the all-on-one-line format easier than
>>  one-line-per-language as well.
>>
>>  To be clear: the issues I find problematic are (1) ambiguity around use
>>  of "*", and (2) the implication of pairing adjacent attributes with each
>>  other in the example without any parallel specification text. My
>>  proposed change is intended to be helpful, although there are clearly
>>  other solutions that address the issues I have identified.
>>
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> People that are really very weird can get into sensitive
> positions and have a tremendous impact on history.
>    --then U.S. Vice President Dan Quayle
>