Re: [Slim] Allowing multiple values in an answer

Bernard Aboba <bernard.aboba@gmail.com> Fri, 12 January 2018 15:44 UTC

Return-Path: <bernard.aboba@gmail.com>
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 B3C8512E881 for <slim@ietfa.amsl.com>; Fri, 12 Jan 2018 07:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LHPB14dtk6vf for <slim@ietfa.amsl.com>; Fri, 12 Jan 2018 07:44:56 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420A2127909 for <slim@ietf.org>; Fri, 12 Jan 2018 07:44:56 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id w22so3843752vkw.0 for <slim@ietf.org>; Fri, 12 Jan 2018 07:44:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X0i9L4KyioI743Xr904beQ2zb5/fup3cwKNZcGDoM8Q=; b=G0Z575qqxdYx27H3ysNAhXtugqxcmt1rBNt1uYPJqKhiwnSm4wqWn1wVzWdQATpfZA Y2VcdtcAPTXFQx1+UcIHW426bymTp7G6cg8XYDDNGltfksI6no8CX2mlJZGkQMyERRoi GcAFVwVdOIhCxpOqBtX/jbDCWuOP1b7/HbSRvBA5ckOBLE6vS2RPL7aJ1vWlB7g32SrM M3WbS64a0khpCHQ5hGf3LGWu8UJCfd7IMujEwiZ5bfiRq/cV3HjfyE9+rljf0hSZqdTI D+AtNi/j3BU2qdPAAGPSI/P0E5/8AJCKNPO4gw2pEWxG+zlh8jKTd1/e+KTr64boR/Ah UZyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X0i9L4KyioI743Xr904beQ2zb5/fup3cwKNZcGDoM8Q=; b=PZOOOBo9GtW6mWowd5QaDXbc3AOqJ7OfImbFX8IDMaKuZdKtUeDwR2b27kO5+bPa7n kAG7CRTYyW4u3/LZMp9ZX3JtLmffOZgx03t/m4tR226Z0Uo4ELMpqyI46XN9P3pCeitq +b41lPAn1wZEGdJFbd+a1nbqb1R3pwxIbhtyDHHxTzl7J3O7eJcYpUoFbWIYXKQo9oo0 xWlhrLfQ/ba/XBM0ydKTfZWjrdyfhRQbs9MLHLfC2lNqDTeMJl3IZT6x32YxNZ5cn0ZC ZvMK/JwWJiJfwT5udN4pOg8lWZ6wYaWH155cWIdOwXv4zD4iBaRUyn/hJY7nLRFgDLeK N2DQ==
X-Gm-Message-State: AKwxytdjfnom8u91IemhWC5XwhPDt8+h/l14slDqB7EIJgmQCoubdMuD CESKNveI/xNceJWNkG4kuinfIiXu1yBoyYlHykwCRegr
X-Google-Smtp-Source: ACJfBotvnAvrDXKxS8gsp6P02j9XEv6yKo8ZbRJD9kmJS06OuGM/mavnQfk/wNWosIEqEXH53MGzEwaVAEHEiLNISVs=
X-Received: by 10.31.82.194 with SMTP id g185mr23985633vkb.15.1515771894986; Fri, 12 Jan 2018 07:44:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.17.239 with HTTP; Fri, 12 Jan 2018 07:44:34 -0800 (PST)
In-Reply-To: <f4ef1525-a2d6-5e8f-2168-31a7cedfd0ff@omnitor.se>
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>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, 12 Jan 2018 07:44:34 -0800
Message-ID: <CAOW+2ds2jf+t9fAJ7wHs=mCZjhapU_f4wNoHTNyn7ABZVc-cTg@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>
Cc: Randall Gellens <rg+ietf@randy.pensive.org>, slim@ietf.org
Content-Type: multipart/alternative; boundary="001a114f76c45c7c2005629625d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/Wr7Lkxo5LDyDAmfj90unyYvI2iI>
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: Fri, 12 Jan 2018 15:45:00 -0000

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