Received changes through RFC Editor sync (changed abstract to '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.')

Received changes through RFC Editor sync (created alias RFC 8373, changed abstract to '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).', changed pages to 13, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-05-24, changed IESG state to RFC Published)

[Ballot comment]
I'm balloting "yes" because I think this is important work, but I have some comments:

Substantive Comments:

- General: It seems to be that this is as much about human behavior as it is capabilities negotiating. Example case: I make a video call and express that I would like to receive Klingon. (Is there a tag for that ? :-) The callee can speak Klingon and Esperanto, so we agree on Klingon. What keeps the callee from speaking Esparanto instead?

I realize we can't force people to stick to the negotiated languages--but should we expect that users should at least be given some sort of UI indication about the negotiated language(s)? It seems like a paragraph or two on that subject is warranted, even if it just to say it's out of scope.

-1, paragraph 6:  (related to Ekr's comments) Does the selection of a single tag in an answer imply  an assumption only one language will be used? There are communities where people tend to mix 2 or more languages freely and fluidly. Is that sort of thing out of scope?

- 5.1, paragraph 2:  Can you elaborate on the motivation to have a separate hlang-send and hlang-recv parameter vs having a single language parameter and instead setting the stream to send or receive only, especially in light of the recommendation to set both directions the same for bi-directional language selection? I don't mean to dispute that approach; I just think a bit more explanation of the design choice would be helpful to the reader.  I can imagine some use cases, for example a speech-impaired person who does not plan to speak on a video call may still wish to send video to show facial expressions, etc.  (I just re-read the discussion resulting from Ekr's comments, and recognize that this overlaps heavily with that.)

-5.1, paragraph 3: "... which in most cases is one of the
  languages in the offer's..."
Are there cases where it might not?

-5.1, last paragraph: "This is not a problem."
Can you elaborate? That sort of statement usually takes the form "This is not a problem, because..."

-5.2, last paragraph: Is there a reason to give such weak guidance on how to indicate the call is rejected?  (Along those lines, are non-SIP uses of SDP in scope?)

Editorial Comments and Nits:

-5.1, paragraph 4: The first MUST seems like a statement of fact.

[Ballot comment]
I'm glad to see this document being published; thanks to everyone to worked on it.

One tiny nit; section 5.1 contains the following text:

>  This document defines two media-level attributes starting with
>  'hlang' (short for "human interactive language")...

I think this is a hold-over from when the string was "humintlang" rather than "hlang" -- it probably makes more sense to say:

>  This document defines two media-level attributes starting with
>  'hlang' (short for "human language")...

[Ballot comment]
== Section 7 ==

"In
  addition, if the 'hlang-send' or 'hlang-recv' values are altered or
  deleted en route, the session could fail or languages
  incomprehensible to the caller could be selected; however, this is
  also a risk if any SDP parameters are modified en route."

Given that one of the primary use cases for the attributes defined here is for emergency calling, it seems worthwhile to call out the new specific threat that these attributes enable in that case, namely the targeted manipulation/forgery of the language attributes for the purposes of denying emergency services to a caller. This general class of attacks is contemplated in Section 5.2.2 of RFC 5069, although there may be a better reference to cite here for what to do if you don't want your emergency calls subject to that kind of attack (I can't recall another document off the top of my head).

== Section 8 ==

This seems weak for not including some words to indicate what to do to mitigate the risks of exposing this information.

[Ballot comment]
One question: I can't really imagine cases where the send and recv would be used to indicate different things. Can you provide an example (and better explain in the document why this 'complexity' was added)?

One purely editorial note: I think section 5.1 could simply be removed before final publication as part of the reasoning is given in the intro already.

[Ballot comment]
Document: draft-ietf-slim-negotiating-human-language-17.txt

1. I'm not marking this first point DISCUSS, but I do think it's
important it be addressed and I trust the AD will ensure that it is.
This document is ambiguous about the contents of the answer
attribute. Specifically, it says:

  In an answer, 'hlang-send' is the language the answerer will send if
  using the media for language (which in most cases is one of the
  languages in the offer's 'hlang-recv'), and 'hlang-recv' is the
  language the answerer expects to receive if using the media for
  language (which in most cases is one of the languages in the offer's
  'hlang-send').

However, the next paragraph permits >1 tag, as does the ABNF in S 6.1.

  Each value MUST be a list of one or more language tags per BCP 47
  [RFC5646], separated by white space.  BCP 47 describes mechanisms for
  matching language tags.  Note that [RFC5646] Section 4.1 advises to
  "tag content wisely" and not include unnecessary subtags.

So, how am I supposed to interpret an answer with >1 tag? Is this
forbidden? I can imagine a number of semantics, but it's important
it be clear in the document.


2. The negotiation structure here does not match that which is
conventionally used with SDP, where each side indicates the formats it
is prepared to receive and the other side can send any of them. Why
did you use this structure? One reason you might is that you expect
the answer to resolve which language is in use, however because SIP
supports early media (i.e., media which is delivered prior to the
answer.)

[Ballot comment]
Thanks for writing an interesting document!

Given that this document doesn’t mandate the behavior in the case of not having languages in common, why does it matter if the combination is “difficult to match together” or not?  I’m wondering about this piece of text (from 5.2):

  ...The
  two SHOULD NOT be set to languages which are difficult to match
  together (e.g., specifying a desire to send audio in Hungarian and
  receive audio in Portuguese will make it difficult to successfully
  complete the call).

I don’t understand how “difficult to match” can be enforced from a normative point of view.  Difficulty seems to be a subjective criteria -- the example shows a pair that I would consider difficult too (I don't speak Hungarian!), but other pairings could still be difficult for me but easy for others.  Using “SHOULD NOT” (instead of “MUST NOT”) implies that there are cases in which it is ok to do it (again, probably subjectively).  It seems to me that the “SHOULD NOT” could be a simple “should not”.

BTW, that reminds me: please use the template text from rfc8174 (instead of rfc2119).

Nit:  It would be nice to expand SPD in the abstract and put a reference to rfc4566 in the Introduction.

[Ballot comment]
Thanks for writing an interesting document!

Given that this document doesn’t mandate the behavior in the case of not having languages in common, why does it matter if the combination is “difficult to match together” or not?  I’m wondering about this piece of text (from 5.2):

  ...The
  two SHOULD NOT be set to languages which are difficult to match
  together (e.g., specifying a desire to send audio in Hungarian and
  receive audio in Portuguese will make it difficult to successfully
  complete the call).

I also don’t understand how “difficult to match” can be enforced from a normative point of view.  Difficulty seems to be a subjective criteria -- the example shows a pair that I would consider difficult too, but other pairings could be difficult for me and might be easy for others.  Using “SHOULD NOT” (instead of “MUST NOT”) implies that there are cases in which it is ok to do it (again, probably subjectively).  It seems to me that the “SHOULD NOT” could be a simple “should not”.

BTW, that reminds me: please use the template text from rfc8174 (instead of rfc2119).

Nit:  It would be nice to expand SPD in the abstract and put a reference to rfc4566 in the Introduction.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-slim-negotiating-human-language-19. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the att-field (media level only) registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

two new registrations will be made as follows:

Type: att-field (media level only)
SDP Name: hlang-recv
Mux Category: NORMAL
Reference: [ RFC-to-be ]

Type: att-field (media level only)
SDP Name: hlang-send
Mux Category: NORMAL
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Warning Codes (warn-codes) registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a new value is to be added to the registry as follows:

Code: [ TBD-at-Registration ]
Description: Incompatible language specification: Requested languages not supported. Supported languages and media are: [list of supported languages and media].
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-12-22):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: slim@ietf.org, alexey.melnikov@isode.com, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-slim-negotiating-human-language-19.txt> (Negotiating Human Language in Real-Time Communications) to Proposed Standard


The IESG has received a request from the Selection of Language for Internet
Media WG (slim) to consider the following document: - 'Negotiating Human
Language in Real-Time Communications'
  <draft-ietf-slim-negotiating-human-language-19.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-12-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Users have various human (natural) language needs, abilities, and
  preferences regarding spoken, written, and signed languages.  This
  document adds new SDP media-level attributes so that when
  establishing interactive communication sessions ("calls"), it is
  possible to negotiate (communicate and match) the caller's language
  and media needs with the capabilities of the called party.  This is
  especially important with emergency calls, 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, but this applies to non-emergency calls as well (as an
  example, when calling a company call center).

  This document describes the need and a solution using new SDP media
  attributes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - )

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.

(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. The header indicates that Standards Track publication is desired.  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?

Within the WG there was disagreement on whether it was necessary to take into account 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 is simpler and more reliable to negotiate and bring up all mutually supported media, then let the conversants decide which
media to use, rather than taking on the additional complexity of negotiating media preferences beforehand.

In particular, it was pointed out that communications quality issues may influence media preferences during a call.  For example, on a call where audio, video and text
all all available, sending video may interfere with audio quality so that video sending needs to be disabled.  Alternatively, audio quality may be poor so that the conversants
need to resort to chat.  Therefore media quality issues that cannot be predicted prior to call establishment 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?

As far as I am aware, there are no current implementations of draft-ietf-slim-negotiating-language.  However, the North American Emergency Number Association (NENA) has already 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 co-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 co-chairs (Bernard Aboba and Natasha Rooney) have reviewed the document. We believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Given the interest in this document within NENA and 3GPP, it would be desirable to forward the IETF Last Call announcement to those SDOs, so as to encourage their review.  It may also be desirable
to forward the IETF Last Call announcement to organizations concerned with communications accessibility for the disabled, since this document has implications for accessibility services such as the
Video Relay Service (VRS).

(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 th
at took place.

Individuals knowledgeable about language negotiation have 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 uncomf
ortable with certain parts 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 do
cument, 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 most probably requires 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?

As part of WG Last Call process, the SLIM WG Chairs requested on the mailing list that all relevant IPR disclosures be made by the
end of WG Last Call on August 12, 2016.  In the presentation to the SLIM WG, it was 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-06 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?

WG consensus represented the concurrence of those WG participants who weighed in on it, with the exception of Gunnar Helstrom who believed that it is necessary to negotiate media preference.

(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 questionnaire 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.14.01  /var/www/.idnits

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  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.

(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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-slim-negotiating-human-language-06.txt. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the att-field (media level only) subregistry of the Session Description Protocol (SDP) Parameters registry located at:

https://www.iana.org/assignments/sdp-parameters/

two new registrations are to be made as follows:

Type: att-field (media level only)
SDP Name: humintlang-recv
MUX Category:
Reference: [ RFC-to-be ]

Type: att-field (media level only)
SDP Name: humintlang-send
MUX Category:
Reference: [ RFC-to-be ]

IANA Services Operator Question --> What should the MUX Category be for these two new registrations?

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
CC: slim@ietf.org, alexey.melnikov@isode.com, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-slim-negotiating-human-language-06.txt> (Negotiating Human Language in Real-Time Communications) to Proposed Standard


The IESG has received a request from the Selection of Language for
Internet Media WG (slim) to consider the following document:
- 'Negotiating Human Language in Real-Time Communications'
  <draft-ietf-slim-negotiating-human-language-06.txt> as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-02-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Users have various human (natural) language needs, abilities, and
  preferences regarding spoken, written, and signed languages.  When
  establishing interactive communication ("calls") there needs to be a
  way to negotiate (communicate and match) the caller's language and
  media needs with the capabilities of the called party.  This is
  especially important with emergency calls, 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, but this applies to non-emergency calls as well (as an
  example, when calling a company call center).

  This document describes the need and a solution using new SDP stream
  attributes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - )
Note that some of these references may already be listed in the acceptable Downref Registry.

(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. The header indicates that Standards Track publication is desired.  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?

Within the WG there was disagreement on whether it was necessary to take into account 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 is simpler and more reliable to negotiate and bring up all mutually supported media, then let the conversants decide which
media to use, rather than taking on the additional complexity of negotiating media preferences beforehand.

In particular, it was pointed out that communications quality issues may influence media preferences during a call.  For example, on a call where audio, video and text
all all available, sending video may interfere with audio quality so that video sending needs to be disabled.  Alternatively, audio quality may be poor so that the conversants
need to resort to chat.  Therefore media quality issues that cannot be predicted prior to call establishment 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?

As far as I am aware, there are no current implementations of draft-ietf-slim-negotiating-language.  However, the North American Emergency Number Association (NENA) has already 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 co-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 co-chairs (Bernard Aboba and Natasha Rooney) have reviewed the document. We believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Given the interest in this document within NENA and 3GPP, it would be desirable to forward the IETF Last Call announcement to those SDOs, so as to encourage their review.  It may also be desirable
to forward the IETF Last Call announcement to organizations concerned with communications accessibility for the disabled, since this document has implications for accessibility services such as the
Video Relay Service (VRS).

(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 th
at took place.

Individuals knowledgeable about language negotiation have 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 uncomf
ortable with certain parts 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 do
cument, 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 most probably requires 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?

As part of WG Last Call process, the SLIM WG Chairs requested on the mailing list that all relevant IPR disclosures be made by the
end of WG Last Call on August 12, 2016.  In the presentation to the SLIM WG, it was 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-06 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?

WG consensus represented the concurrence of those WG participants who weighed in on it, with the exception of Gunnar Helstrom who believed that it is necessary to negotiate media preference.

(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 questionnaire 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.14.01  /var/www/.idnits

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  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.

(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.

We are pleased to announce that this draft has entered into Working Group Last Call. We will aim to exit WGLC on 12th August, which gives us three week from today.

Issues: if you have issues please submit these to the IETF Issue Tracker at [1]. Please feel free to discuss items on the list also.

[1] https://tools.ietf.org/wg/slim/trac/newticket