Re: [Slim] WG Action: Formed Selection of Language for Internet Media (slim)

Hi All,

I mentioned this off list to Randall, but the Milestone for
draft-tomkinson-slim-multilangcontent needs to be updated to Mar 2016 as
there is some testing required for further refinement and also some
thinking on a new section so this will not meet the original deadline of
November.

Can this get updated please?

Thanks,

Nik.

On 16 October 2015 at 17:53, The IESG <iesg-secretary@ietf.org> wrote:

> A new IETF working group has been formed in the Applications and
> Real-Time Area. For additional information please contact the Area
> Directors or the WG Chairs.
>
> Selection of Language for Internet Media (slim)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Chairs:
>   Bernard Aboba <Bernard_Aboba@hotmail.com>
>   N Rooney <nrooney@gsma.com>
>
> 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:
>
> 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 start by producing specifications for email and for
> real-time communications.
>
> In the email case, the group will determine a MIME based solution (based
> on draft-tomkinson-slim-multilangcontent) 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.  Alternatives such as doing the media
> negotiation in SIP have been explored in the past and are out of scope
> (although SIP-based mechanisms may be introduced when routing
> considerations are addressed).
>
> The group's initial focus will not be on supporting language-based call
> routing decisions.  Once the initial work is sufficiently progressed, the
> group may  address call routing, with the timing at the judgment of the
> chairs.
>
> Recognizing that complex solutions are significantly less
> likely to see widespread deployment, the group will solve the most
> common use cases and avoid adding complexity to solve edge or
> less-common cases.
>
> 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:
>   Nov 2015 - Submit "Multiple Language Content Type" to the IESG (based
> on draft-tomkinson-slim-multilangcontent)
>   Mar 2016 - Submit "Negotiating Human Language in Real-Time
> Communications" to the IESG (based on
> draft-gellens-slim-negotiating-human-language)
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
>

-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

<http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/

-----------------------------------------------------------------