Re: [Slim] [rfc-dist] RFC 8373 on Negotiating Human Language in Real-Time Communications

[William_J_G Overington <[e-mail]>]

Hi

I am new to all of this and do not know a lot about it, but I was reading RFC 8373 and I noticed something in RFC 8373 to which my own research project seems to relate.

As my research project, if its content becomes implemented as part of information technology in the future, may possibly affect section 5.2, I wonder if I may mention my research project here please in the hope that whether or not it relates to section 5.2 of RFC 8373 can be assessed by experts please.

Please consider the following document. The webspace is my family webspace. It is a "free when purchasing dial-up internet access" webspace that dates back to 1997. I have been using broadband for many years now and the dial-up internet access facility closed some years ago but I have been allowed to keep the webspace for a small fee each year. It keeps its original name but is now hosted by Plusnet PLC which took over the company that took over the original provider. I mention this as the hosting webspace may be unknown to you.

http://www.users.globalnet.co.uk/~ngo/a_completed_publication_about_localizable_sentences_research.pdf

The document is 74.13 kilobytes in size.

I have for some time considered the possibility of, for research purposes, using the language tag x-y for communication using localizable sentences technology.

Thus if a section 5.2 No Language in Common situation arises, an offer of x-y could be made and if both parties to the communication agree then localizable sentences technology could be used to communicate through the language barrier: the scope of the communication might well be limited, but nonetheless could be very helpful in some situations, for example a medical emergency, where meanings such as "What is your name?" and "What is your address?" could be communicated through the language barrier. The nature of localizable sentences technology is to use the Universal Character Set, so a message can include both encoded localizable sentences and plain text, so a reply to asking for a name and an address and so on could mix both localizable sentences, which would be displayed localized; and plain text that would be displayed exactly as it is sent.

I would be interested to know your comments please.

I am new to replying to an RFC so I have replied to every address in the original message distribution list and also to the author whose name is listed in RFC 8373. I am not sure as to whether that means that this email will go to everybody on the list, or to a moderator, or just to a few people.

Yours sincerely

William Overington

Friday 25 May 2018




----Original message----
>From : [e-mail]
Date : 2018/05/25 - 00:50 (GMTDT)
To : [e-mail], [e-mail]
Cc : [e-mail], [e-mail], [e-mail]
Subject : [rfc-dist] RFC 8373 on Negotiating Human Language in Real-Time Communications

A new Request for Comments is now available in online RFC libraries.

        
        RFC 8373

        Title:      Negotiating Human Language in Real-Time 
                    Communications 
        Author:     R. Gellens
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2018
        Mailbox:    [e-mail]
        Pages:      13
        Characters: 27727
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-slim-negotiating-human-language-24.txt

        URL:        https://www.rfc-editor.org/info/rfc8373

        DOI:        10.17487/RFC8373

Users have various human (i.e., natural) language needs, abilities,
and preferences regarding spoken, written, and signed languages.
This document defines new Session Description Protocol (SDP) media-
level attributes so that when establishing interactive communication
sessions ("calls"), it is possible to negotiate (i.e., communicate
and match) the caller's language and media needs with the
capabilities of the called party.  This is especially important for
emergency calls, because it allows for a call to be handled by a call
taker capable of communicating with the user or for a translator or
relay operator to be bridged into the call during setup.  However,
this also applies to non-emergency calls (for example, calls to a
company call center).

This document describes the need as well as a solution that uses new
SDP media attributes.

This document is a product of the Selection of Language for Internet Media Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org