Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Sun, 07 January 2018 14:35 UTC

Return-Path: <ekr@rtfm.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 9703E126579 for <slim@ietfa.amsl.com>; Sun, 7 Jan 2018 06:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 gi4wFin1LN4S for <slim@ietfa.amsl.com>; Sun, 7 Jan 2018 06:35:21 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 860A812422F for <slim@ietf.org>; Sun, 7 Jan 2018 06:35:21 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id 5so3591093ybp.4 for <slim@ietf.org>; Sun, 07 Jan 2018 06:35:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MbEYu7avxzfmtHkcg5/Gb/ls5Al6Wpo1YjTomxLZLjQ=; b=Odxo8Jgb3sM+nhJLOE57ijtu4JavFR5GmGdLy2evWu6sKYSw/k1I8Yu+8wSfEPaETO dH9AowkPDfVVjMf9tsEkh6fNcjJOi2jyl7hxrsYOXR/tcONdTy3LMto1hu2EmrUtJs7t vzWJyuCd+rkCLEMiLIRIMPlVj9eN61sFO+8AddRl6Cqg2zsiupXni4UhU8kfXVD9+0+D h/mYDDNGR2dPeEKS7sqC4eWHfFmha54VTyrjCubkYrLdP29MfeWn40OjO1eOQrlN6tJb QTIql/F6mRy8QZ2jagNxykN80h2LUdQStWg8NIpTFDu2zYpmrKLZiRte71kE2z3/3CZt 9grg==
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=MbEYu7avxzfmtHkcg5/Gb/ls5Al6Wpo1YjTomxLZLjQ=; b=buLbP7rrCmbiT4WVDCkgGorMfwB+kl5aL8z4+LbUr8ZqxcC8eFS4kz+sT8ikBuhpOQ VrvYRzuazlazoPHn3Y8PRX5CBLNNDSZcZjQ07Ssbzn2XpnO+Dy8kt676JR7q51Xd/8o8 4gED6tyUaiUvTclpnLMH2vlEl7/2RpmHLVuClQxkIZDrKKhWzh6WylFgsC91E6mZMG4r 3Y4UFWO3u9Kos8yoMusXm9ivIDEQlIkI3/HmGNiv0CgqfHCD7Yci/C8etiFhwB74oVqQ 4zVuk5Y0eAi3gYYoAPb9HPtnvW8nTPGeKinuvW4AFjTodBxWmiG3+p5R4Z7S2kVSq7wz rSFA==
X-Gm-Message-State: AKGB3mJUROg3z/OtVs3jwOjQS/xi+6QiOM9nWwj1xWHc+7XXlh0Nk6fQ NYYJtDxzNIvZXhim8m+6OfOAz6xGDBbwbHGja3FMtg==
X-Google-Smtp-Source: ACJfBotkj3tpRG90eK2J02TCGdgV7cbFSodI5fPoorOGV4wtuLJLxfigFwoZumFQLdR7BXXo1jq/2x4w3RkL1x6zZ5Q=
X-Received: by 10.37.239.79 with SMTP id w15mr3065110ybm.293.1515335720513; Sun, 07 Jan 2018 06:35:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Sun, 7 Jan 2018 06:34:39 -0800 (PST)
In-Reply-To: <p06240601d67742276cd4@99.111.97.136>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com> <p06240601d67742276cd4@99.111.97.136>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 7 Jan 2018 06:34:39 -0800
Message-ID: <CABcZeBOR=XbNN_tR8-XE_UJ3=Xak5Qaim4xQQMLuTCiWmxXY7A@mail.gmail.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: The IESG <iesg@ietf.org>, slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: multipart/alternative; boundary="089e0828a13c5661df056230972b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/hwNztO34_WRCVJdr0DTWPAODPck>
Subject: Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
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: Sun, 07 Jan 2018 14:35:24 -0000

On Sat, Jan 6, 2018 at 7:22 PM, Randall Gellens <rg+ietf@randy.pensive.org>
wrote:

> At 5:39 PM -0800 1/6/18, Eric Rescorla wrote:
>
>  Document: draft-ietf-slim-negotiating-human-language-17.txt
>>
>>  1. I'm not marking this first point DISCUSS, but I do think it's
>>  important it be addressed and I trust the AD will ensure that it is.
>>  This document is ambiguous about the contents of the answer
>>  attribute. Specifically, it says:
>>
>>     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').
>>
>>  However, the next paragraph permits >1 tag, as does the ABNF in S 6.1.
>>
>>     Each value MUST be a list of one or more language tags per BCP 47
>>     [RFC5646], separated by white space.  BCP 47 describes mechanisms for
>>     matching language tags.  Note that [RFC5646] Section 4.1 advises to
>>     "tag content wisely" and not include unnecessary subtags.
>>
>>  So, how am I supposed to interpret an answer with >1 tag? Is this
>>  forbidden? I can imagine a number of semantics, but it's important
>>  it be clear in the document.
>>
>
> Thank you for catching this.  I think the first paragraph is correct and
> the second paragraph and ABNF are in error, they were copied from the offer
> and not fixed.  The intent is that a single language per direction be
> arrived it per media stream.
>
>
>  2. The negotiation structure here does not match that which is
>>  conventionally used with SDP, where each side indicates the formats it
>>  is prepared to receive and the other side can send any of them. Why
>>  did you use this structure? One reason you might is that you expect
>>  the answer to resolve which language is in use, however because SIP
>>  supports early media (i.e., media which is delivered prior to the
>>  answer.)
>>
>
> In light of my reply to (1), do you still feel that the negotiation
> structure doesn't match usual offer/answer behavior?


Yes. That doesn't necessarily mean it's wrong, of course. Conventions are
just that, conventions.

-Ekr


>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> We do not stop playing because we grow old; we grow old because we stop
> playing.             --U.S. Supreme Court Justice Oliver Wendell Holmes
>