Re: [Slim] Allowing multiple values in an answer

[Gunnar Hellström <[e-mail]>]

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]