Re: [Slim] Allowing multiple values in an answer

[Bernard Aboba <[e-mail]>]

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 <[e-mail]> 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 
> [e-mail] 
> [phone] 
> 
> 
> 
> -------- Originalmeddelande --------
> Från: Bernard Aboba <[e-mail]> 
> Datum: 2018-01-12 16:44 (GMT+01:00) 
> Till: Gunnar Hellström <[e-mail]> 
> Kopia: Randall Gellens <[e-mail]>, [e-mail] 
> 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 <[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 list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/slim
>> 
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [e-mail]
>> [phone]
>