Re: [Slim] Allowing multiple values in an answer

[Bernard Aboba <[e-mail]>]

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]
>
>