Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01
Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 24 July 2013 00:05 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7C11E8195 for <mmusic@ietfa.amsl.com>; Tue, 23 Jul 2013 17:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.195
X-Spam-Level:
X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfYgxfKS2BoQ for <mmusic@ietfa.amsl.com>; Tue, 23 Jul 2013 17:05:43 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32111E8193 for <mmusic@ietf.org>; Tue, 23 Jul 2013 17:05:42 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3znR1m00116LCl05505hgz; Wed, 24 Jul 2013 00:05:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 405h1m01H3ZTu2S3S05hax; Wed, 24 Jul 2013 00:05:41 +0000
Message-ID: <51EF1A54.2070302@alum.mit.edu>
Date: Tue, 23 Jul 2013 20:05:40 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: mmusic@ietf.org
References: <51EEC4A8.9050108@alum.mit.edu> <51EF0546.6000604@omnitor.se>
In-Reply-To: <51EF0546.6000604@omnitor.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374624341; bh=mviMsZn/pYCjFQotc1NxGecAdVy5Unh9iH0GzsR/m0A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WRhA8v8QErn8xLrqF1pzAd3KgIhlE1KuZib74BC69SqjkMItxTD12y6JModaLKmbT hTrRQOgCWYu/4F0Tb6TrC9KJY2aeKRja+Z4cN+G0J8GPBlbErOcophlWGr9WcdPW6Z oqDzcb6P8Pb3ubmsmAkzBSjVRzDe0H2Qks5i1PLcpi8UxQkxDhcpPxpRjxMyDNifH+ BU9dD4pS9FpDyVwcT/08XFDYXLOyYTVj3UYht4emiji3JY3VkwPbBLwL6hIjJA4+/N F1QEyejeMn7l8BNdYvMDyt03asz15I38tilsD67U5ioB122LehfjgKht+jhV3eIS8d bu5o9NgeXVwvw==
Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 00:05:49 -0000
On 7/23/13 6:35 PM, Gunnar Hellstrom wrote: > > On 2013-07-23 20:00, Paul Kyzivat wrote: >> I just reviewed this new version. I have a number of comments: > Good comments Paul, >> >> * 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.) > <GH>Yes, very useful to indicate all. >> >> * 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. >> > <GH>Have you seen my request for an indication of level of preference > between the different modalities? A possiblility to indicate for example > that British Sign Language is highly preferred, but English text possible. > The q values could be used for coding of such relative level of > preference even between modalities. a q=1 for BSL in video, and a q=0.1 > for English in text. Right? That would work within a single medium. But I don't think we can use that mechanism to trade off between different media. For that I think some other, more complex, mechanism would be needed. Or else we would need a more complex definition of which things are being prioritized against one another in order to use the q-values. >> 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. > <GH>This is both a threat and a solution. There are already other > reasons to group media in SDP. We have a risk of ending up in a very > complex coding in SDP to get this correctly specified in an environment > where there are also other reasons to group m-lines. This is why I am > still hesitating if the whole thing would not fit better as tags on the > SIP level. I notice Henning just asked about this today, in a different forum. Perhaps some things are better done at the sip level, and others at the SDP level. Its also possible that correlations between different media streams should be left to other mechanisms. E.g., CLUE could signal better correlations between audio and video. Thanks, Paul >> >> 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?) > <GH>I have asked for deletion of this limiting paragraph. >> >> 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. > <GH>Yes, I prefer that view. The answering part shall answer if it can. > middleboxes or the offering part may do the invocation of services to > cover the gaps. >> >> * 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. > > <GH>Yes, tricky. I am getting a feeling that we should start a draft > describing usage in parallel to this one, so that use cases can be > verified. > >> >> Need more discussion for how to denote this. >> >> Thanks, >> Paul >> > Gunnar >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- Re: [MMUSIC] Orlando time for human language draf… Randall Gellens
- [MMUSIC] Update on Orlando time for human languag… Randall Gellens
- Re: [MMUSIC] Update on Orlando time for human lan… Paul Kyzivat
- Re: [MMUSIC] Orlando time for human language draf… Randall Gellens
- Re: [MMUSIC] Orlando time for human language draf… Eric Burger
- Re: [MMUSIC] Update on Orlando time for human lan… Randall Gellens
- Re: [MMUSIC] Update on Orlando time for human lan… Harald Alvestrand
- Re: [MMUSIC] Update on Orlando time for human lan… DRAGE, Keith (Keith)
- Re: [MMUSIC] Update on Orlando time for human lan… Randall Gellens
- Re: [MMUSIC] Update on Orlando time for human lan… Harald Alvestrand
- Re: [MMUSIC] Update on Orlando time for human lan… Gunnar Hellstrom
- Re: [MMUSIC] Update on Orlando time for human lan… Randall Gellens
- Re: [MMUSIC] Update on Orlando time for human lan… Randall Gellens
- Re: [MMUSIC] Update on Orlando time for human lan… Gunnar Hellstrom
- Re: [MMUSIC] Update on Orlando time for human lan… Randall Gellens
- Re: [MMUSIC] Update on Orlando time for human lan… Gunnar Hellstrom
- Re: [MMUSIC] Update on Orlando time for human lan… Randall Gellens
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Paul Kyzivat
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Gunnar Hellstrom
- [MMUSIC] draft-gellens-mmusic-negotiating-human-l… Paul Kyzivat
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Gunnar Hellstrom
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Randall Gellens
- Re: [MMUSIC] draft-gellens-mmusic-negotiating-hum… Gunnar Hellstrom
- [MMUSIC] Toronto time for human language draft di… Randall Gellens