Re: [Slim] Allowing multiple values in an answer

"Randall Gellens" <rg+ietf@randy.pensive.org> Thu, 15 February 2018 22:37 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 CF6E612704A for <slim@ietfa.amsl.com>; Thu, 15 Feb 2018 14:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WCZKc3U38KUU for <slim@ietfa.amsl.com>; Thu, 15 Feb 2018 14:36:53 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1987F12DB6B for <slim@ietf.org>; Thu, 15 Feb 2018 14:36:53 -0800 (PST)
Received: from [99.111.97.174] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 15 Feb 2018 14:37:45 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: "Bernard Aboba" <bernard.aboba@gmail.com>
Cc: "Gunnar =?utf-8?q?Hellstr=C3=B6m?=" <gunnar.hellstrom@omnitor.se>, slim@ietf.org
Date: Thu, 15 Feb 2018 14:36:49 -0800
X-Mailer: MailMate Trial (1.10r5443)
Message-ID: <64A8A716-9AB6-4CF6-AE76-1E92AD6454F4@randy.pensive.org>
In-Reply-To: <CAOW+2ds2jf+t9fAJ7wHs=mCZjhapU_f4wNoHTNyn7ABZVc-cTg@mail.gmail.com>
References: <151555808122.21584.8379796998643581181.idtracker@ietfa.amsl.com> <p06240602d67be148b9db@99.111.97.136> <2c49d430-3fb1-381f-d236-4bc5a6a38c27@omnitor.se> <CAOW+2dtDBKR5q_LO9=kTpgKQJR=P_hy4yzQC=iy8q_WgtH6hyw@mail.gmail.com> <p06240601d67d2f9e1693@99.111.97.136> <p06240603d67d6aa5ec31@99.111.97.136> <p06240604d67d70904f55@99.111.97.136> <p06240606d67d8fbc9d90@99.111.97.136> <f4ef1525-a2d6-5e8f-2168-31a7cedfd0ff@omnitor.se> <CAOW+2ds2jf+t9fAJ7wHs=mCZjhapU_f4wNoHTNyn7ABZVc-cTg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_E4F8F9B0-0CB6-473F-9C70-C2CFC437C0DE_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[1628, 9824], "plain":[1183, 7133], "uuid":"A3FFF17B-623A-414E-8012-96B116F5C91F"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/q_D0JWL9AG8sTZBmxLe8eMp9Im4>
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: Thu, 15 Feb 2018 22:37:01 -0000

I checked older versions of the draft, and the text seems to clearly 
indicate that one language per media is negotiated.  This is why I 
resolved the ambiguity between the text and the ABNF in favor of the 
text.  That said, I don’t personally mind if we were to resolve it the 
other way, and proposed an edit that would do so, but I do feel that the 
intent of the text has been clear for some time.  For example, here is 
the text in a version from November 2014:

    In an offer, the 'humintlang-send' values constitute a list in
    preference order (first is most preferred) of the languages the
    offerer wishes to send using the media, and the 'humintlang-recv'
    values constitute a list in preference order of the languages the
    offerer wishes to receive using the media. …

    In an answer, 'humintlang-send' is the accepted language the 
answerer
    will send (which in most cases is one of the languages in the 
offer's
    'humintlang-recv'), and 'humintlang-recv' is the accepted language
    the answerer expects to receive (which in most cases is one of the
    languages in the offer's 'humintlang-send').

—Randall

On 12 Jan 2018, at 7:44, Bernard Aboba wrote:

> 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 
>> listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitorgunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>


> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim


--Randall