Re: [Slim] Allowing multiple values in an answer

Bernard Aboba <bernard.aboba@gmail.com> Sat, 13 January 2018 02:01 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE2C126C2F for <slim@ietfa.amsl.com>; Fri, 12 Jan 2018 18:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXDr8tFOLGG0 for <slim@ietfa.amsl.com>; Fri, 12 Jan 2018 18:01:48 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A24120726 for <slim@ietf.org>; Fri, 12 Jan 2018 18:01:48 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id 23so5689894pfp.3 for <slim@ietf.org>; Fri, 12 Jan 2018 18:01:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Eg6gpSdjMTnE+x38oImxwkc8SA6EiAPSvm2iG4A038E=; b=Z7RjvbOheqwc9+pg3MQ4OapIx4uj6W1dwBxI+bPfuj1npjflJSVVh9edqvMKGYDv03 2l0YlXvovVaGukFXLtEUMDwdAWYSmSSzYDNExck4FCAzqs/gQmLjM1lEOEGEK2BOMRQU 191vUF6KQoOfWDGAjMajljnhnD8ijuN07nn5c0PFH6faxsIhGhqJPukxLNtaXPOPsCqL hu7Sqb+fe98sH+/QLYbFbKJryr/WrUvcNivSdqQJAKBV2ZaD3HiZla9+r6byAz9ZBJd2 6G73Tma/+Txb0FI9fTcv6BAPIvmoc/oCM09wdr1zujCyRPxXxMunA1eo5QXs1paQIgYy +cBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Eg6gpSdjMTnE+x38oImxwkc8SA6EiAPSvm2iG4A038E=; b=gTEja7qZdgqUXrfU7v4eC6tsKd+xcYmDhzQATYgBTJW4yFe6BidkbyF0W1yQKAjsRt R2iTypRGTNdHqAJawnv5no1JT1A/LsWL9FRL6fuHG+eb47F37egeNCl6QmBxVvRcRIhq TlvxHAxS7zwUvTRJSppAqO1HgnO4yhBk6CwHHllUeSMoPXKSHDcU1k99hoL2Wl700ANE E6nLoAqEHOwkIS+9dLFDzsdfhlKxPFzhG761P2WB+VX7VLBMtHjGtpr+lMWCnNW/2fTh rOkclztfM55tR0AHaqpweZ0+E5yGuzx5MPJfjxJW8CvvB3uGMXNXCB6tzOWObkZkNbQd d3hw==
X-Gm-Message-State: AKGB3mLX3gKMgXR3cbNN9LigessThiD75i6j6BTTRjmHX5VGzHhS1AC+ Yr7eRbPLcxJ+EdO878M7XEzDBVva
X-Google-Smtp-Source: ACJfBotUiTj3HkMKKK5PYFPPjMniNXKsRGjY9tkLE0UNDF36/gBmobK+KHQvJeUSdNiBWJEo5+fh0Q==
X-Received: by 10.98.7.85 with SMTP id b82mr24854161pfd.226.1515808907388; Fri, 12 Jan 2018 18:01:47 -0800 (PST)
Received: from [192.168.1.101] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id y5sm49823510pfd.63.2018.01.12.18.01.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 18:01:46 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-189FB2C7-8526-4859-8C3B-E2A4CD02A518
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPad Mail (15C202)
In-Reply-To: <vxsogec0ay8gbnpr053n0urr.1515799528320@email.android.com>
Date: Fri, 12 Jan 2018 18:01:45 -0800
Cc: Randall Gellens <rg+ietf@randy.pensive.org>
Content-Transfer-Encoding: 7bit
Message-Id: <AA7F9218-DAC8-489B-A075-E6AC0DA3B0E1@gmail.com>
References: <vxsogec0ay8gbnpr053n0urr.1515799528320@email.android.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>, slim@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/_iqxWsrJJqZ6VpoS-b4quOLgicw>
Subject: Re: [Slim] Allowing multiple values in an answer
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jan 2018 02:01:51 -0000

It seems to me that the SDP codec design pattern (multiple languages in offer, multiple in Answer, with the first language in the Offer being the “primary” language for that media) is most natural. 

But I’m speaking only as a participant, not as Chair and would love to hear more opinions from the WG.

> On Jan 12, 2018, at 15:25, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
> 
> Bernard, I agree with your analysis, and I have made my proposal for the progress.
> Do you have a conclusion and directive as shepherd, or do you want a comment from the reviewers?
> 
> /Gunnar
> 
> 
> Gunnar Hellström  
> Omnitor 
> gunnar.hellstrom@omnitor.se 
> +46 708 20 42 88 
> 
> 
> 
> -------- Originalmeddelande --------
> Från: Bernard Aboba <bernard.aboba@gmail.com> 
> Datum: 2018-01-12 16:44 (GMT+01:00) 
> Till: Gunnar Hellström <gunnar.hellstrom@omnitor.se> 
> Kopia: Randall Gellens <rg+ietf@randy.pensive.org>rg>, slim@ietf.org 
> Rubrik: Re: [Slim] Allowing multiple values in an answer 
> 
> Gunnar said: 
> 
> "<GH> The IESG review started on version -19, where we had normative language for allowing multiple languages per media and direction, and non-normative but quite clear wording (using "is" ) for saying that the intention is to have one language per media and direction intended for use. 
> 
> When this difference was questioned, you changed the normative language, while others suggested to change the non-normative language. I still think that it would be better to change the non-normative language so that multiple languages per media and direction are allowed. I do not see how that would conflict the review situation, but we might need a judgment on that from the reviewers. "
> 
> [BA]  Yes, -19 did not have normative language about the number of languages in the Answer and the ABNF allowed multiple languages.  Also, -19 did not have normative language about whether the languages in the Answer need to be present in the Offer.  The closest (from -23) is this sentence: 
> 
>    In an answer, 'hlang-send' is the language the answerer will send if
>    using the media for language (which in most cases is one of the
>    languages in the offer's 'hlang-recv'), and 'hlang-recv' is the
>    language the answerer expects to receive if using the media for
>    language (which in most cases is one of the languages in the offer's
>    'hlang-send').
> 
> Section 5.4 includes an example Answer which includes Italian in response to an Offer of Spanish, Basque and English. 
> 
> 
> 
> 
> 
>> On Fri, Jan 12, 2018 at 2:54 AM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:
>>> Den 2018-01-11 kl. 23:04, skrev Randall Gellens:
>>> I realized an additional change was needed, to the discussion of the offer/answer model.  Attached is a revised diff. 
>>> 
>>> At 11:57 AM -0800 1/11/18, Randall Gellens wrote: 
>>> 
>>>>  The second of the two remaining open questions is if we should allow an answer to contain multiple values.  I do not think this is the intent of the text that has been in the draft for some time; regardless, we could make such a change, but I question if we can do so now, when we've essentially passed IESG review. 
>> <GH> The IESG review started on version -19, where we had normative language for allowing multiple languages per media and direction, and non-normative but quite clear wording (using "is" ) for saying that the intention is to have one language per media and direction intended for use. 
>> 
>> When this difference was questioned, you changed the normative language, while others suggested to change the non-normative language. I still think that it would be better to change the non-normative language so that multiple languages per media and direction are allowed. I do not see how that would conflict the review situation, but we might need a judgment on that from the reviewers. 
>> 
>> I provided one reason yesterday why it would be better to only have one language in the answer, but I now realize that that was false. I said that one language provides better opportunity for the offeror to prepare for receiving the selected language.  But even if the answer contains more than one language, the answering party should still follow the order of preference, and start the call using the first language in the hlang-send attribute in the media in the answer selected for use. So, all arguments point at it being better to allow more than one language in the answer per media and direction.  
>> 
>> It also solves an unfair difference we have, that it is possible to list more than one language per direction if you include languages in different media, but not for a single media. I see no logical reason for that difference, and I do not want to give up the freedom to indicate support of language in multiple media for the same direction.
>> 
>> The offeror has the best opportunity for assessing which extra resources would be needed in the call after receiving the answer. I know that there may currently be economical and policy obstacles for making use of that opportunity, but it would be sad to block it by not providing the full view of the support in the answer. 
>> 
>> I find the diff you sent to be good, and also version -23 solving all other issues in a good way. So, I vote for applying your proposed changes on -23 and hope that that can be the final version.
>> 
>> --------------------------------------------------------------------------------------------------------------------------------------------------
>> I also want to throw in food for thought, that I realize is too late in the process, but still worth thinking about:
>> We could just as well have defined attributes only for the directions of use of the media for language, and let the "lang" attribute list the languages. The "lang" attribute has a better definition in rfc4566bis than before, and the main improvement we provide is that we can indicate direction of use of the language. We recommend strongly against having different preferences and languages in the different directions of a media, so one language list would be sufficient per media, and the new attributes could be limited to use a selection of a=hlang-send  and a=hlang-recv per media without their own language lists.  Sorry for the late discovery of this condition.
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>> Gunnar 
>>>> 
>>>>  I edited a version of the draft that contains all remaining clarifying editorial changes to also make this technical change and attached is a diff showing what it would look like.  However, I think we should not make the change since it could introduce additional complexities or problems that we aren't considering.  I think we could make such a change in a future extension or revision.  I don't think we'd have an interoperability problem since endpoints conformant with the more restrictive version will not generate such answers, and would regard regard receiving such answers as an error, but not one that would fail a call. 
>> 
>>>> 
>>>>  -- 
>>>>  Randall Gellens 
>>>>  Opinions are personal;    facts are suspect;    I speak for myself only 
>>>>  -------------- Randomly selected tag: --------------- 
>>>>  [XML] is probably the worst format ever designed...it really doesn't scale as a 
>>>>  file format, and it's generally a complete disaster. --Linus Torvalds, 3/6/2014 
>>>> 
>>>> 
>>>>  Attachment converted: TiLand:diff-with-multiple 1.pdf (    /    ) (008B9E88) 
>>>>  _______________________________________________ 
>>>>  SLIM mailing list 
>>>>  SLIM@ietf.org 
>>>>  https://www.ietf.org/mailman/listinfo/slim 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> SLIM mailing list
>>> SLIM@ietf.org
>>> https://www.ietf.org/mailman/listinfo/slim
>> 
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
>