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

From: "Sabrina Tanamal via RT" <[email-masked]>
Date: Tue, 28 Mar 2017 20:31:36 +0000

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" <[email-masked]>
CC:	"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
To:	[email-masked]
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.

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.

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*

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.

/a

____
[1] https://www.ietf.org/iesg/directorate/sdp.html

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Mar 2017 17:12:02 -0500

For some reason, this message did not make its way onto the mailing list.

----

From:   "Adam Roach" <[email-masked]>
CC:     "[email-masked]" <[email-masked]>, "
[email-masked]" <[email-masked]>, [email-masked]
To:     [email-masked]
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

Hide quoted text

m=audio 49250 RTP/AVP 20
a=hlang-send:es eu en *
a=hlang-recv:es eu en *

/a

____

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Mar 2017 16:54:10 -0700

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
>
>  ----
>
>  CC:	"[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, [email-masked]
>  Subject:	SDPDIR Review: Review of 
> draft-ietf-slim-negotiating-human-language-08
>  Download (untitled)
>  /
>  with headers
>
>  text/plain 3.9KiB

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.

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

>>  even if the callee does not support any of the languages:

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.

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

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 30 Mar 2017 11:14:21 +0200

I notice that the comments and solution proposal on the syntax concerns 
from the IANA review has a lot in common with Issue 34.

https://trac.ietf.org/trac/slim/ticket/34

Both propose a one-line format for all languages in one media and 
direction, and both are puzzled by the diffuse placement rules for the 
asterisk parameter.

A solution could be searched on these together.

Gunnar

Den 2017-03-28 kl. 22:31, skrev Sabrina Tanamal via RT:
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288