Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language

Adam Roach <adam@nostrum.com> Wed, 26 April 2017 21:15 UTC

Return-Path: <adam@nostrum.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 330F11294FD for <slim@ietfa.amsl.com>; Wed, 26 Apr 2017 14:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 61NCBYF_bmlL for <slim@ietfa.amsl.com>; Wed, 26 Apr 2017 14:15:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 16C6D127342 for <slim@ietf.org>; Wed, 26 Apr 2017 14:15:15 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QLFCax084137 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 16:15:13 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, Bernard Aboba <bernard.aboba@gmail.com>, slim@ietf.org
References: <CAOW+2dtU+sbM=7tYYr0m8t3D6eyKiKo_ShVhoAjaKOBuJYpdNw@mail.gmail.com> <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se>
From: Adam Roach <adam@nostrum.com>
Message-ID: <a3fcb80c-0c7d-db0f-8c14-5c4e09ef5773@nostrum.com>
Date: Wed, 26 Apr 2017 16:15:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <15feb90b-15f3-8ac9-ea01-fd271a4ff086@omnitor.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/zBHEodJw1LJVlmJ7RMTpDYC5ITQ>
Subject: Re: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language
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: Wed, 26 Apr 2017 21:15:16 -0000

On 4/26/17 3:55 PM, Gunnar Hellström wrote:
>
> Bernard, thanks for the summary. We need decisions on these issues and 
> move on.
>
> How do you propose that decisions are taken?
>
> A brief comment on #38 - routing: My memory of the discussion and 
> decision is that we would not describe the routing logic and actions, 
> but we should aim at producing indications that would have high 
> likelihood to be usable for routing calls to appropriate call parties. 
> Thus it needs to be possible to interrogate the indications by proxies 
> even if TLS is used.
>

TLS is hop-by-hop in SIP (meaning it hides exactly nothing from 
proxies), so that's not an issue. The chances of S/MIME being broadly 
deployed in SIP do seem kind of slim, but thinking about what would 
happen if the body were encrypted is a good litmus test for "have I 
*really* messed up my layering?"

Given that the direction selected by the WG is to represent language 
values in SDP, I think this document can *either* say that routing is 
100% out of scope and unaddressed, *or* it can add some SIP-level header 
fields that bear on routing according to human languages. Anything that 
tries to split the difference is likely to cause architectural pain in 
the future, and an approach that I would counsel very strongly against.

/a