[secdir] [new-work] WG Review: Selection of Language for Internet Media (slim)

The IESG <iesg@ietf.org> Fri, 26 June 2015 15:36 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64C1A8791; Fri, 26 Jun 2015 08:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435332969; bh=ukYrK34ZJdFYjZMwiFNeD8KumlxWG4NoaYDX6Q1+xg4=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fdw0J82nfhRHOXcrqF/BLNUmr9c2aGf/2BTxloW+j8eVWPW8J/SDQNyPsb2uaJG/5 6TEEATCAr262z3DSaSNrPoFMvWhTeQCccmq06ATtgo6PUcbxPcjGRX6IxlwJiJnMDu LaWJ3nP7IRqpBtMmOOCVcJp1c10EiF/06TurA8Bc=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5E1A8791; Fri, 26 Jun 2015 08:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 jtQFsIgSeytl; Fri, 26 Jun 2015 08:36:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD61A8784; Fri, 26 Jun 2015 08:36:05 -0700 (PDT)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150626153605.18943.13946.idtracker@ietfa.amsl.com>
Date: Fri, 26 Jun 2015 08:36:05 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/new-work/eF6bKAiffyCNZlKdy7mcQ-OYRnY>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: new-work <new-work-bounces@ietf.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/4x9B_ReGKNegbdaCzEwoC-UZtUo>
X-Mailman-Approved-At: Fri, 26 Jun 2015 09:17:54 -0700
Subject: [secdir] [new-work] WG Review: Selection of Language for Internet Media (slim)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2015 15:36:09 -0000

A new IETF working group has been proposed in the Applications and
Real-Time Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2015-07-06.

Selection of Language for Internet Media (slim)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Barry Leiba <barryleiba@computer.org>

Mailing list
  Address: slim@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/slim
  Archive: https://mailarchive.ietf.org/arch/browse/slim/

Charter:

Description of Working Group:

A mutually comprehensible language is helpful for human communication. 
This is true across a range of circumstances and environments.  In
general, the problem is most acute in situations where there is not a
clear choice for a single language, such as environments lacking
contextual or out-of-band information regarding the identity of the
parties and the language to be used.

The group will address two specific cases that most urgently need a
technical solution: One problem space is non-real-time communication,
specifically email for one-to-many or where the set of recipients is
dynamic or different recipients require different languages; the other is
real-time communication, specifically emergency calling, preferably also
useful for other cases where the parties may not know each other
personally or where one party wishes to accommodate people with varying
language and media needs.

In the real-time communication case, language and media are intrinsically
linked, for example, signed languages require a video media.

While the two use cases are in different contexts (real time and
non-real-time), the fundamental goal is the same: to enable selection of
the best-fit language(s) for a specific situation.  Some of the details
will also be in common across the cases, e.g., the language tags.  Having
a single WG address both cases makes it clear that these are two aspects
of the same basic problem.  A single WG also makes it easier to maximize
similarities and avoid unnecessary fragmentation of the solutions, and
facilitates broader review.

The group will produce two documents, one for email, and one for
real-time communications.

In the email case, the group will determine a MIME based solution that
enables a single email message to contain multiple language versions of
the content, with provisions to help clients select a best fit version.

In the real-time communication case, the group will produce a
specification based on draft-gellens-slim-negotiating-human-language,
enabling negotiation of a human language per media stream.  The
specification must be suitable for use in emergency communications as
specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate
media); it is desirable to also be suitable for use in non-emergency
real-time communications that share the same call set-up and media
negotiation protocols.  The mechanism will permit the caller's media and
language needs and preferences to be matched against what the called
party is able to provide.  The mechanism will permit resources (e.g.,
translation, relay, media) to be allocated or engaged as early as
possible in the call set-up or for the call to be routed or handled
specially (e.g., routed to a resource able to provide a needed language
and/or media).  Alternatives such as doing the negotiation in SIP have
been thoroughly explored in the past and are out of scope (although the
scope might be extended after the SDP mechanism has been advanced).

By adding language to the existing media negotiation mechanism as used in
RFC 6443 and RFC 6881, the group can meet the basic use cases with
minimal added complexity and be able to enhance later for additional use
cases as needed.

Milestones:
  Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based
on draft-tomkinson-slim-multilangcontent)
  Feb 2016 - Submit "Negotiating Human Language in Real-Time
Communications" to the IESG (based on
draft-gellens-slim-negotiating-human-language)


_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work