[MMUSIC] draft-gellens-mmusic-negotiating-human-language-01

[Paul Kyzivat <[e-mail]>]

I just reviewed this new version. I have a number of comments:

* Section 5:

You don't go into the details of the O/A rules. But I infer you assume 
that the answer will be a subset of the offer, with the priorities 
possibly changed. This is a common strategy with SDP O/A, but it is 
limiting because it doesn't allow the answerer to indicate capabilities 
it has that weren't mentioned by the offerer. Knowing that could be 
useful, especially if a mismatch is going to result in recruiting a 
relay service.

I suggest that answer allow the answerer to indicate all of its 
capabilities and preferences, and at the same time indicate choices 
made. (If a choice was made.)

* Section 7.1:

Instead of humanintlang-send and humanintlang-recv, how about just 
giving the lang tag and a send/recv/sendrecv parameter with it? This 
would be more concise when sendrecv can be used.

Suggest using a parameter (q) to indicate relative preference for 
languages, rather than ordering. This can show degree of preference, and 
can show when multiple languages have the same preference.

Example:

a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5

To accommodate my comment about section 5, perhaps the answer can "mark" 
the alternative(s) that have been chosen for use, if any. (I'm not sure 
I like this, but for now, lets assume a "*" suffix on the direction in 
the answer.) E.g., assuming the offer above, then an answer like:

a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5

Also in this section, the following:

    Note that while signed language tags are used with a video stream to
    indicate sign language, a spoken language tag for a video stream in
    parallel with an audio stream with the same spoken language tag
    indicates a request for a supplemental video stream to see the
    speaker.

might be ambiguous in the presence of many streams. It might be good to 
define a grouping framework (RFC 5888) usage to group an audio stream 
with a video stream that contains the speaker(s) of the audio.

Also in this section, the following:

    Clients acting on behalf of end users are expected to set one or both
    'humintlang-send' and 'humintlang-recv' attributes on each media
    stream in an offer when placing an outgoing session but ignore the
    attributes when receiving incoming calls.  Systems acting on behalf
    of call centers and PSAPs are expected to take into account the
    values when processing inbound calls.

Are you intending to exclude clients taking a more active role? (E.g., 
Isn't it possible that a client receiving an incoming call in a language 
it doesn't support might bridge in a relay service?)

Should a client that can't do anything useful with the language info 
still indicate its language preferences in the answer? I would think 
this would still be helpful. It might allow the caller, or a middlebox, 
to compensate in some way. What I suggest above allows that.

* Section 7.2 (Advisory vs Required):

Rather than "*" suffix, would be cleaner to have a separate indicator. 
And it seems like this should not be on a particular language tag. If 
you speak both Spanish and English, you may want the call to succeed if 
the callee can do one or the other, and otherwise fail. A tag per 
language doesn't do that.

Need more discussion for how to denote this.

	Thanks,
	Paul