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

Randall Gellens <rg+ietf@randy.pensive.org> Sun, 07 January 2018 03:22 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 B3477120726; Sat, 6 Jan 2018 19:22:40 -0800 (PST)
X-Quarantine-ID: <1EAy3cVguGjJ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 1EAy3cVguGjJ; Sat, 6 Jan 2018 19:22:39 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8E120713; Sat, 6 Jan 2018 19:22:39 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 6 Jan 2018 19:23:10 -0800
Mime-Version: 1.0
Message-Id: <p06240601d67742276cd4@[99.111.97.136]>
In-Reply-To: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com>
References: <151528917109.10947.12045320996364596931.idtracker@ietfa.amsl.com>
X-Mailer: Eudora for Mac OS X
Date: Sat, 06 Jan 2018 19:22:36 -0800
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/-i_GttmUFj1zzyuQHkhyP_MTqX8>
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 03:22:41 -0000

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?

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