Document Writeup for draft-ietf-slim-negotiating-human-language-19
Document Shepard: Bernard Aboba (bernard.aboba@gmail.com)
(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:
Technical Summary:
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
during setup.
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 additional complexity.
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 defined.
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.
Document Quality:
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.
Personnel:
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:
https://mailarchive.ietf.org/arch/msg/slim/JSBakIqte8mSpdlbzDqNSWSrEyU
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.
idnits 2.15.00
tmp/draft-ietf-slim-negotiating-human-language-19.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
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.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (December 1, 2017) is 6 days in the past. Is this
intentional?
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?
Yes.
(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.
No.
(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.
No.
(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.