Negotiating Human Language in Real-Time Communications
RFC 8373
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21 |
24 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2018-12-19 |
24 | (System) | 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 … 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.') |
2018-05-31 |
24 | (System) | Received changes through RFC Editor sync (added Errata tag) |
2018-05-24 |
24 | (System) | 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 … 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) |
2018-05-24 |
24 | (System) | RFC published |
2018-05-24 |
24 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-24 |
24 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-03-28 |
24 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-02-27 |
24 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-02-26 |
24 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-02-22 |
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-02-20 |
24 | (System) | RFC Editor state changed to EDIT |
2018-02-20 |
24 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-02-20 |
24 | (System) | Announcement was received by RFC Editor |
2018-02-20 |
24 | (System) | IANA Action state changed to In Progress |
2018-02-20 |
24 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2018-02-20 |
24 | Amy Vezza | IESG has approved the document |
2018-02-20 |
24 | Amy Vezza | Closed "Approve" ballot |
2018-02-20 |
24 | Amy Vezza | Ballot approval text was generated |
2018-02-20 |
24 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-24.txt |
2018-02-20 |
24 | (System) | New version approved |
2018-02-20 |
24 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2018-02-20 |
24 | Randall Gellens | Uploaded new revision |
2018-01-16 |
23 | Alexey Melnikov | Waiting for the WG to reach consensus on a few remaining issues |
2018-01-11 |
23 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-23.txt |
2018-01-11 |
23 | (System) | New version approved |
2018-01-11 |
23 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2018-01-11 |
23 | Randall Gellens | Uploaded new revision |
2018-01-11 |
22 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Tom Yu. |
2018-01-11 |
22 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-01-10 |
22 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-01-10 |
22 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-01-09 |
22 | Ben Campbell | [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 … [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. |
2018-01-09 |
22 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-01-09 |
22 | Adam Roach | [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 … [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")... |
2018-01-09 |
22 | Adam Roach | Ballot comment text updated for Adam Roach |
2018-01-09 |
22 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-01-09 |
22 | Alissa Cooper | [Ballot comment] == Section 7 == "In addition, if the 'hlang-send' or 'hlang-recv' values are altered or deleted en route, the session could … [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. |
2018-01-09 |
22 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-01-09 |
22 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-22.txt |
2018-01-09 |
22 | (System) | New version approved |
2018-01-09 |
22 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2018-01-09 |
22 | Randall Gellens | Uploaded new revision |
2018-01-09 |
21 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-21.txt |
2018-01-09 |
21 | (System) | New version approved |
2018-01-09 |
21 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2018-01-09 |
21 | Randall Gellens | Uploaded new revision |
2018-01-08 |
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-01-08 |
20 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-20.txt |
2018-01-08 |
20 | (System) | New version approved |
2018-01-08 |
20 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2018-01-08 |
20 | Randall Gellens | Uploaded new revision |
2018-01-08 |
19 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-01-08 |
19 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-01-08 |
19 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-01-08 |
19 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-01-08 |
19 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-01-08 |
19 | Mirja Kühlewind | [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 … [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. |
2018-01-08 |
19 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-01-06 |
19 | Eric Rescorla | [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 … [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.) |
2018-01-06 |
19 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-01-06 |
19 | Alvaro Retana | [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, … [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. |
2018-01-06 |
19 | Alvaro Retana | Ballot comment text updated for Alvaro Retana |
2018-01-06 |
19 | Alvaro Retana | [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, … [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. |
2018-01-06 |
19 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-01-06 |
19 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-01-06 |
19 | Alexey Melnikov | Ballot has been issued |
2018-01-06 |
19 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-01-06 |
19 | Alexey Melnikov | Created "Approve" ballot |
2018-01-06 |
19 | Alexey Melnikov | Ballot writeup was changed |
2017-12-23 |
19 | Dale Worley | Request for Last Call review by GENART Completed: Ready. Reviewer: Dale Worley. Sent review to list. |
2017-12-22 |
19 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-12-21 |
19 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-12-21 |
19 | Sabrina Tanamal | (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 … (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 |
2017-12-14 |
19 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2017-12-14 |
19 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2017-12-08 |
19 | Cindy Morgan | 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 … 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 - ) |
2017-12-08 |
19 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-12-08 |
19 | Cindy Morgan | Last call announcement was generated |
2017-12-08 |
19 | Alexey Melnikov | Placed on agenda for telechat - 2018-01-11 |
2017-12-08 |
19 | Alexey Melnikov | Last call was requested |
2017-12-08 |
19 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2017-12-08 |
19 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2017-12-07 |
19 | Bernard Aboba | 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 … 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. |
2017-12-07 |
19 | Bernard Aboba | (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? … (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. |
2017-12-07 |
19 | Bernard Aboba | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2017-12-07 |
19 | Bernard Aboba | IESG state changed to Publication Requested from AD is watching |
2017-12-01 |
19 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-19.txt |
2017-12-01 |
19 | (System) | New version approved |
2017-12-01 |
19 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-12-01 |
19 | Randall Gellens | Uploaded new revision |
2017-11-21 |
18 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-18.txt |
2017-11-21 |
18 | (System) | New version approved |
2017-11-21 |
18 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-11-21 |
18 | Randall Gellens | Uploaded new revision |
2017-10-14 |
17 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-17.txt |
2017-10-14 |
17 | (System) | New version approved |
2017-10-14 |
17 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-10-14 |
17 | Randall Gellens | Uploaded new revision |
2017-10-14 |
16 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-16.txt |
2017-10-14 |
16 | (System) | New version approved |
2017-10-14 |
16 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-10-14 |
16 | Randall Gellens | Uploaded new revision |
2017-10-13 |
15 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-15.txt |
2017-10-13 |
15 | (System) | New version approved |
2017-10-13 |
15 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-10-13 |
15 | Randall Gellens | Uploaded new revision |
2017-10-13 |
14 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-14.txt |
2017-10-13 |
14 | (System) | New version approved |
2017-10-13 |
14 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-10-13 |
14 | Randall Gellens | Uploaded new revision |
2017-07-17 |
13 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-13.txt |
2017-07-17 |
13 | (System) | New version approved |
2017-07-17 |
13 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-07-17 |
13 | Randall Gellens | Uploaded new revision |
2017-07-01 |
12 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-12.txt |
2017-07-01 |
12 | (System) | New version approved |
2017-07-01 |
12 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-07-01 |
12 | Randall Gellens | Uploaded new revision |
2017-06-23 |
11 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-11.txt |
2017-06-23 |
11 | (System) | New version approved |
2017-06-23 |
11 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@coretechnologyconsulting.com> |
2017-06-23 |
11 | Randall Gellens | Uploaded new revision |
2017-05-29 |
10 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-10.txt |
2017-05-29 |
10 | (System) | New version approved |
2017-05-29 |
10 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@randy.pensive.org>, slim-chairs@ietf.org |
2017-05-29 |
10 | Randall Gellens | Uploaded new revision |
2017-05-29 |
10 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@randy.pensive.org> |
2017-05-29 |
10 | Randall Gellens | Uploaded new revision |
2017-05-29 |
09 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-09.txt |
2017-05-29 |
09 | (System) | New version approved |
2017-05-29 |
09 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@randy.pensive.org> |
2017-05-29 |
09 | Randall Gellens | Uploaded new revision |
2017-03-31 |
08 | Alexey Melnikov | IESG state changed to AD is watching from Waiting for Writeup |
2017-03-31 |
08 | Alexey Melnikov | Returned to the WG for further discussion after IETF LC. |
2017-03-31 |
08 | Alexey Melnikov | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2017-03-06 |
08 | Mahesh Jethanandani | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Mahesh Jethanandani. Sent review to list. |
2017-02-26 |
08 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-08.txt |
2017-02-26 |
08 | (System) | New version approved |
2017-02-26 |
08 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@randy.pensive.org> |
2017-02-26 |
08 | Randall Gellens | Uploaded new revision |
2017-02-22 |
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-02-22 |
07 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-07.txt |
2017-02-22 |
07 | (System) | New version approved |
2017-02-22 |
07 | (System) | Request for posting confirmation emailed to previous authors: Randall Gellens <rg+ietf@randy.pensive.org> |
2017-02-22 |
07 | Randall Gellens | Uploaded new revision |
2017-02-20 |
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-02-17 |
06 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2017-02-17 |
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-02-17 |
06 | Sabrina Tanamal | (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 … (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 |
2017-02-10 |
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2017-02-10 |
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2017-02-09 |
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tom Yu |
2017-02-09 |
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tom Yu |
2017-02-07 |
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2017-02-07 |
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2017-02-06 |
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-02-06 |
06 | Amy Vezza | 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> … 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. |
2017-02-06 |
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-02-06 |
06 | Amy Vezza | Last call announcement was changed |
2017-02-04 |
06 | Alexey Melnikov | Last call was requested |
2017-02-04 |
06 | Alexey Melnikov | Last call announcement was generated |
2017-02-04 |
06 | Alexey Melnikov | Ballot approval text was generated |
2017-02-04 |
06 | Alexey Melnikov | Ballot writeup was generated |
2017-02-04 |
06 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2017-02-04 |
06 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2017-02-03 |
06 | Alexey Melnikov | (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? … (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. |
2017-02-03 |
06 | Alexey Melnikov | Responsible AD changed to Alexey Melnikov |
2017-02-03 |
06 | Alexey Melnikov | Intended Status changed to Proposed Standard |
2017-02-03 |
06 | Alexey Melnikov | IESG process started in state Publication Requested |
2017-02-03 |
06 | (System) | Earlier history may be found in the Comment Log for /doc/draft-gellens-negotiating-human-language/ |
2017-02-03 |
06 | Alexey Melnikov | Working group state set to Submitted to IESG for Publication |
2017-02-03 |
06 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2017-02-03 |
06 | Alexey Melnikov | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2017-02-03 |
06 | Alexey Melnikov | Notification list changed to "Bernard Aboba" <bernard.aboba@gmail.com> |
2017-02-03 |
06 | Alexey Melnikov | Document shepherd changed to Dr. Bernard D. Aboba Ph.D. |
2017-02-02 |
06 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-06.txt |
2017-02-02 |
06 | (System) | New version approved |
2017-02-02 |
06 | (System) | Request for posting confirmation emailed to previous authors: "Randall Gellens" <rg+ietf@randy.pensive.org> |
2017-02-02 |
06 | Randall Gellens | Uploaded new revision |
2017-02-02 |
06 | (System) | Request for posting confirmation emailed to previous authors: "Randall Gellens" <rg+ietf@randy.pensive.org> |
2017-02-02 |
06 | Randall Gellens | Uploaded new revision |
2017-02-01 |
05 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-05.txt |
2017-02-01 |
05 | (System) | New version approved |
2017-02-01 |
05 | (System) | Request for posting confirmation emailed to previous authors: "Randall Gellens" <rg+ietf@randy.pensive.org> |
2017-02-01 |
05 | Randall Gellens | Uploaded new revision |
2017-02-01 |
05 | (System) | Request for posting confirmation emailed to previous authors: "Randall Gellens" <rg+ietf@randy.pensive.org> |
2017-02-01 |
05 | Randall Gellens | Uploaded new revision |
2017-01-22 |
04 | (System) | Document has expired |
2016-07-25 |
04 | Natasha Rooney | 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 … 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 |
2016-07-25 |
04 | Natasha Rooney | IETF WG state changed to In WG Last Call from WG Document |
2016-07-21 |
04 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-04.txt |
2016-07-21 |
03 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-03.txt |
2016-07-20 |
02 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-02.txt |
2016-03-21 |
01 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-01.txt |
2015-11-02 |
00 | Bernard Aboba | This document now replaces draft-gellens-negotiating-human-language, draft-gellens-slim-negotiating-human-language instead of None |
2015-11-02 |
00 | Randall Gellens | New version available: draft-ietf-slim-negotiating-human-language-00.txt |