Re: [Slim] Allowing multiple values in an answer

["Randall Gellens" <[e-mail]>]

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 <
> [e-mail]> 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
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>
>>
>>
>> _______________________________________________
>> SLIM mailing 
>> [e-mail]://www.ietf.org/mailman/listinfo/slim
>>
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> [e-mail]
>> [phone]
>>
>>


> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim


--Randall