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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I believe that this Charter is poorly suited to developing solutions to the problem faced by disabled users of realtime emergency services.  

In the case of access to emergency services by the disabled, the goal is not "selection of the best-fit language", but rather, routing of the call and media so as to pull together the services best fitting the emergency situation and the disabilities of the caller, as well as the capabilities of the device and intermediaries which may sit between the caller and the PSAP.  Not only are media and language intrinsically linked, but also, the ways in which calls are routed is influenced and in some cases prescribed by regulation and national standards.  

Simply put, draft-gellens-slim-negotiating-human-language lacks appropriate consideration of the problem context.  Specifying it as the starting point is therefore inappropriate. As an example, today the call flow described in Section 4.5 would most likely result in rejection of the video portion of the call by the PSAP, leaving the dispatcher with no means of communicating with the hearing-impaired caller, thus leaving the caller worse off than they are today attempting to make an emergency call within the (cumbersome and error/delay-prone) Video Relay Service.   A fuller consideration of the problem context would involve consideration of current operation of relay services and proposals for their evolution.  Attempting to develop this problem context within a WG that is also attempting to deal with language-selection in email would be frustrating at best. 

A sensible Charter would also probably include liaisons with disability rights organizations, groups specifying the operation of relay services, and groups considering next steps for access to emergency services. 

> From: iesg@xxxxxxxx
> To: new-work@xxxxxxxx
> Date: Fri, 26 Jun 2015 08:36:05 -0700
> Subject: [new-work] WG Review: Selection of Language for Internet Media (slim)
>
> 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@xxxxxxxxxxxx>
>
> Mailing list
> Address: slim@xxxxxxxx
> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/new-work
>

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]