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

[Randall Gellens <[e-mail]>]

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