Document Writeup for draft-ietf-slim-negotiating-human-language-19
Document Shepard: Bernard Aboba (firstname.lastname@example.org)
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
It is requested that this document be published as a Proposed Standard. This document needs to be on the Standards Track
since a standard way to handle language negotiation is needed to ensure interoperability. The document is also likely
to be referenced by regulators, who prefer standards track documents to Informational or Experimental.
(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
In establishing a multi-media communications session, it can be
important to ensure that the caller's language and media needs
match the capabilities of the called party. This is important
in non-emergency uses (such as when calling a company call
center) or in emergencies where a call can be handled by a
call taker capable of communicating with the user, or a
translator or relay operator can be bridged into the call
This document describes the problem of negotiating human
(natural) language needs, abilities and preferences
in spoken, written and signed languages. It also provides
a solution using new stream attributes within the Session
Description Protocol (SDP).
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
This draft has undergone 13 revisions since its initial IETF last call (which occurred on draft -06). These
revisions were required to address issues raised by the IETF community, such as:
1. The meaning of the "*" in language negotiation. The SDP directorate review in the initial IETF last call expressed concern
over the handling of the asterisk, which had the properties of a session attribute while being included within individual m-lines.
WG consensus was to remove the asterisk, whose role had been advisory.
2. Routing of calls. The SDP directorate review in the initial IETF last call expressed concern about whether the document
intended the use of SDP for routing of SIP traffic. Language was added to indicate clearly that call routing was
out of scope.
3. Combining of hlang-send/hlang-recv. In IETF last call, a reviewer suggested that the document allow combining the
hlang-send and recv indications so as to allow more efficient representation in cases where language preference is
symmetrical. This suggestion was not accepted by the WG since it was not clear that the efficiency was worth the
In addition to issues brought up in IETF last call, there was substantial WG discussion on the following points:
4. Undefined language/modality combinations. Language tags do not always distinguish spoken from written
language, so some combinations of languages and media are not well defined. The text in Section 5.4
resulted from WG discussion of several scenarios:
a. Captioning. While the document supports negotiation of sign language in a video stream, it does not
define how to indicate that captioning (e.g. placement of text within the video stream) is desired.
WG Consensus did not support use of suppressed script tags for this purpose.
b. SignWriting (communicating sign language in written form). Currently only a single language tag has been defined
for SignWriting so that written communication of sign language in a text stream (or in captioning) is also not
c. Lipreading (spoken language within video). There was not WG consensus for explicitly indicating
the desire for spoken language in a video stream (e.g. by use of the -Zxxx script subtag), since the
ability to negotiate "lip sync" is already provided in RFC 5888.
As a result of these discussions, Section 5.4 leaves a number of potential combinations of language and
media undefined. Assuming that implementation experience shows a need to define these scenarios, they
can be addressed in future work.
5. Preferences between media. As an example, an individual might be able to understand written English communicated using
Realtime Text, but might prefer spoken English audio. The current draft enables all modes of communication to be
negotiated, but does not indicate a preference between them. WG consensus was that it was acceptable and
possibly more reliable for mutually supported media to be negotiated and brought up, then let the conversants
decide which media to use, rather than taking on the additional complexity of negotiating media preference beforehand.
During discussion, it was pointed out that quality issues could influence media preferences during a call.
For example, on a call where audio, video and text are all available, sending video may interfere with
audio quality so that video sending needs to be disabled. Alternatively, audio quality could be poor so that
the conversants need to resort to text. So media quality issues can negate the "best laid plans" of
media preference negotiation.
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
There are no current implementations of draft-ietf-slim-negotiating-language. However, the North American Emergency Number Association
(NENA) has referenced it in NENA 08-01 (i3 Stage 3 version 2) in describing attributes of emergency calls presented to an ESInet and
within 3GPP some CRs introduced in SA1 have referenced the functionality. Therefore implementation is expected.
Who is the Document Shepherd? Who is the Responsible Area Director?
Bernard Aboba (SLIM WG Chair) is the Document Shepard. The responsible area director is Alexey Melnikov (ART AD).
(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to the IESG.
The SLIM WG Chair (Bernard Aboba) has reviewed the document and believes it is ready for publication.
(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
In the first IETF last call, the document was reviewed very thoroughly, and in the process of addressing the comments, document quality has markedly improved.
(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
If so, describe the review that took place.
In the first IETF last call, individuals knowledgeable about SDP, SIP and language negotiation reviewed the document.
The SDP security concerns of this document are similar to those that arise with SDP generally (e.g. the
desirability of transporting SDP in confidential manner, such as via SIP over TLS).
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?
For example, perhaps he or she is uncomfortable with certain pats of the document, or has concerns whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
It should be understood that this document by itself does not solve the problem of routing of emergency calls from disabled users.
That problem will require the addition of headers to SIP, similarly to how RFC 6442 defined Location Conveyance for SIP.
(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Prior to this request for publication, the SLIM WG Chair explicitly requested that the author of this document acknowledge
that all relevant IPR discloses have been made prior to advancement. He acknowledged this requirement:
Also, WG chairs have noted that RFC 6071 provides for sanctions to be applied to violators of the IETF IPR policy.
The text sent to the mailing list on Fri, 22 July 2016 was as follows:
"As noted in the WG session on Tuesday, RFC 6701 ("Sanctions Available for
Application to Violators of IETF IPR Policy") notes that:
it is important to understand that the impact that an IPR disclosure has
on the smooth working of the IETF is directly related to how late in
the process the disclosure is made.
Our expectation is that IPR declarations will be submitted by the end of WG
last call on 12 August."
No IPR disclosures were received by the deadline, nor have any disclosures been received since then.
draft-ietf-slim-negotiating-human-language-19 claims to be in full conformance with the provisions of BCP 78 and BCP 79.
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosures have been filed.
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
Only two editorial comments were provided in the last WG last call.
At this point, the document has responded to the thorough review provided in an initial IETF last call, which has greatly improved document clarity and quality.
Also, the WG discussion that occurred in response to those reviews widened the discussion within the WG. With the subsequent narrowing of the document's scope,
I believe that there is strong consensus for what remains.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this questionaire is publicly available.)
No appeals have been threatened.
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.
Checking boilerplate required by RFC 5378 and the IETF Trust (see
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
No issues found here.
-- The document date (December 1, 2017) is 6 days in the past. Is this
Checking references for intended status: Proposed Standard
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
I believe that the formal review criteria have been met.
(13) Have all references within this document been identified as either normative or informative?
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
There are no normative references to drafts, only RFCs.
(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the docume
nt makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a d
etailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226)
The current IANA considerations section requests the allocation of new SDP attributes. The section is in conformance with RFC 4566, but not with the template suggested in RFC 4566bis.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
There are no new IANA registries created by this document.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
This document does not utilize any formal languages.