idnits 2.17.1 draft-hellstrom-slim-modality-grouping-01.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 3, 2018) is 2305 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-24) exists of draft-ietf-slim-negotiating-human-language-19 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SLIM G. Hellstrom 3 Internet-Draft Omnitor 4 Intended status: Standards Track January 3, 2018 5 Expires: July 7, 2018 7 Human Language Modality Grouping Semantics in Session Description 8 Protocol 9 draft-hellstrom-slim-modality-grouping-01 11 Abstract 13 When setting up a real-time communication session, there may be a 14 need to indicate preference for which media and modality (spoken, 15 written or signed) to use for language communications or a need to 16 indicate preference for receiving the same language content 17 simultaneously in two modalities. This document defines the 18 semantics for grouping media for such purposes in the Session 19 Description Protocol (SDP). The semantics defined in this document 20 are based on the SDP Grouping Framework. Applications are for 21 example negotiation the most suitable common modality or modalities 22 for language communications in a real-time session. The indications 23 are specified for the sending and receiving direction separately. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 7, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Requirements for Modality Grouping . . . . . . . . . . . . . 4 62 3.1. Simultaneous Use of Different Modalities . . . . . . . . 4 63 3.2. Preference for Language in Different Modality . . . . . . 4 64 4. Modality Grouping . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Simultaneous Use of Different Modalities . . . . . . . . 4 66 4.2. Preference for Language in Different Modality . . . . . . 5 67 5. SDP Offer/Answer Considerations . . . . . . . . . . . . . . . 5 68 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Desire by caller to receive both spoken and written 70 language form of media . . . . . . . . . . . . . . . . . 6 71 6.2. High preference by caller to receive sign language and 72 lower preference for text. . . . . . . . . . . . . . . . 7 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 10. Changes from earlier versions . . . . . . . . . . . . . . . . 9 77 10.1. Changes from draft-hellstrom-slim-modality-grouping-00 78 to draft-hellstrom-slim-modality-grouping-01 . . . . . . 9 79 10.2. Changes from draft-hellstrom-language-grouping-00 to 80 draft-hellstrom-slim-modality-grouping-00 . . . . . . . 10 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 11.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 In certain applications it is of interest to indicate a need for, or 89 the availability of, transformed version of the contents of a media 90 stream in another media and modality, while still also providing the 91 original. 93 The application may for example be for indication of rapid subtitling 94 of speech either manually or automatically. It may also be for 95 indication of sign language interpretation of speech, or spoken 96 interpretation of sign language when both the original and the 97 interpretation is delivered to the user. 99 This specification defines an indication that language contents in 100 one modality is desired simultaneously with a different modality. 101 The mechanism used is based on the Session Description Protocol (SDP) 102 Grouping Framework [RFC5888] and used with SDP [RFC4566]. The same 103 indication is used for indication of preparedness to send language 104 contents in one modality simultaneously with same content in a 105 different modality. 107 When starting a conversation in a media-rich environment, the users 108 may have very specific preferences for using one modality (spoken, 109 written or signed) over other possible but less preferred modalities. 110 In traditional call establishment, it is the answering part who is 111 expected to start the conversation by a greeting. In the media-rich 112 environment, the modality and language of this greeting sets the 113 expectations for what modality and language to mainly use in the 114 session. Deviation from this initial expectation is usually possible 115 during the session by mutual agreement between the participants, but 116 may be time consuming and cause uncertainty. 118 A way for the parties to thoroughly describe the desired language 119 communication for a session as well as providing information about 120 less preferred alternatives is specified. The indication includes 121 information of alternative languages and modalities for the 122 communication directions in the session, and also indication of 123 preference for specific modalities per direction. This specification 124 defines a mechanism for indicating modality preference based on the 125 Session Description Protocol (SDP) Grouping Framework [RFC5888]. 127 The expected application area is wide. By old tradition, the most 128 common modality for real-time interaction is spoken communication. 129 In some settings, e.g. where silence is required, it may be desirable 130 to express a preference for using written communication, while still 131 leaving a possibility open for traditional spoken communication by an 132 indication on lower preference level. For persons having full 133 ability to both use sign language and spoken language, but not 134 wanting to force the other party to bring in a sign language 135 interpreter in the call, it may be of importance to be able to 136 indicate the sign language capability on a lower preference level and 137 the spoken language capability on a higher level. Some persons may 138 strongly prefer to conduct a written conversation, while still 139 wanting to express that a spoken conversation is possible as a last 140 resort. Many other situations exist in the media-rich communication 141 environment when the modality preference indication is of value for a 142 smooth initiation of a real-time session. 144 The mechanisms for specifying simultaneous use of language in 145 different modalities and preference between modalities specified in 146 this document may be combined with a mechanism for specifying 147 language use in media specified in other documents. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Requirements for Modality Grouping 157 3.1. Simultaneous Use of Different Modalities 159 The grouping semantics for indication of simultaneous use of 160 different media for different transforms of the same language shall 161 have the ability to indicate: 163 o That the language contents of one media is desired or offered also 164 simultaneously in a transformed form in other media grouped with 165 the first. 167 o The direction of language communication that the indication is 168 valid for; sending or receiving as seen from the party providing 169 the SDP. 171 3.2. Preference for Language in Different Modality 173 The grouping semantics for indication of relative preference between 174 use for language communication in different media and modalities 175 shall have the ability to indicate: 177 o The order of preference for receiving or providing language 178 contents in the media included in a grouping. 180 o The direction of language communication that the indication is 181 valid for; sending or receiving as seen from the party providing 182 the SDP. 184 4. Modality Grouping 186 4.1. Simultaneous Use of Different Modalities 188 The "Human Language Simultaneous Send" (HLSS) and "Human Language 189 Simultaneous Receive" (HLSR) grouping semantics and the SDP "group" 190 attribute defined in [RFC5888] are used to associate media in which 191 it is indicated that different transforms of the same content is 192 either desired to be received by a party or offered for sending by a 193 party. 195 The "a=group:HLSS" semantics SHOULD be used to indicate media 196 grouping for preparedness for sending of same language contents in 197 different transforms in all media included in the group. 199 The "a=group:HLSR" semantics SHOULD be used to indicate media 200 grouping for preference for reception of language contents in 201 different transforms in all media in the group. 203 The HLSS and HLSR semantics MAY be used together with mechanisms for 204 detailing language use in media. One such mechanism is 205 [I-D.ietf-slim-negotiating-human-language]. 207 4.2. Preference for Language in Different Modality 209 The "Human Language Preferred Send" (HLPS) and "Human Language 210 Preferred Receive" (HLPR) grouping semantics and the SDP "group" 211 attribute defined in [RFC5888] are used to associate media among 212 which it is indicated an order of preference for using the media for 213 language contents. The order of preference is that the media 214 identity first in the group has highest preference and the following 215 have lower preference in the same order as they appear in the group 216 definition. 218 The "a=group:HLPS" semantics SHOULD be used to indicate media 219 grouping for preparedness for sending of language contents with 220 preference in the same order as the media identities appear in the 221 group with the first having highest preference. 223 The "a=group:HLPR" semantics SHOULD be used to indicate media 224 grouping for preference for reception of language contents with 225 preference in the same order as the media identities appear in the 226 group with the first having highest preference. 228 The HLPS and HLPR semantics MAY be used together with mechanisms for 229 detailing language use in media. One such mechanism is 230 [I-D.ietf-slim-negotiating-human-language]. 232 5. SDP Offer/Answer Considerations 234 The following SDP offer/answer considerations according to [RFC3264] 235 apply. 237 An application that understands the received HLSR, HLSS, HLPR or HLPS 238 grouping semantics SHOULD make efforts to satisfy the preferences 239 expressed by the grouping semantic. 241 The answer SHOULD include HLSR, HLSS, HLPR or HLPS grouping semantics 242 corresponding to what the answering application prefers to receive 243 and what the answering application is prepared to send, best matching 244 the received preference indications and its own capabilities. The 245 answering party SHOULD make best effort to transmit language contents 246 in media and modality according to the answer. 248 The offering party SHOULD analyze the answer and make best effort to 249 transmit language contents in media according to the answer. 251 The grouping semantics defined in this document are only informing 252 about language contents disposition in media and SHOULD NOT be taken 253 as reasons to enable or reject media streams. 255 Media not included in any HLPR or HLPS grouping are assumed to be 256 assigned lower preference for being used for language communication 257 than the ones included in HLPR or HLPS grouping. 259 If the HLSR, HLSS, HLPR or HLPS grouping semantics are used without 260 any further language specifications, video media SHOULD be assumed to 261 be used for sign language, audio media for spoken language and text 262 media for written language. 264 Note that grouping of "m" lines MUST always be requested by the 265 offerer, but never by the answerer. Since SIP provides a two-way SDP 266 exchange, an answerer that requested grouping would not know whether 267 the "group" attribute was accepted by the offerer or not. An 268 answerer that wants to group media lines SHOULD issue another offer 269 after having responded to the first one (in a re-INVITE, for 270 instance). 272 6. Examples 274 6.1. Desire by caller to receive both spoken and written language form 275 of media 277 v=0 279 o=Laura 289083124 289083124 IN IP4 two.example.com 281 c=IN IP4 233.252.0.1/127 283 t=0 0 285 a=group:HLSR 1 2 287 m=audio 30000 RTP/AVP 0 288 a=mid:1 290 m=text 30002 RTP/AVP 98 97 292 a=mid:2 294 m=video 30004 RTP/AVP 34 296 a=mid:3 298 Note that also the video media needs to include a 'mid' attribute 299 even when it is not included in any grouping for the grouping to be 300 valid. 302 An answer can confirm that both desired media will contain the same 303 language contents. 305 v=0 307 o=Laura 289083124 289083124 IN IP4 two.example.com 309 c=IN IP4 233.252.0.1/127 311 t=0 0 313 a=group:HLSS 1 2 315 m=audio 30000 RTP/AVP 0 317 a=mid:1 319 m=text 30002 RTP/AVP 98 97 321 a=mid:2 323 m=video 30004 RTP/AVP 34 325 a=mid:3 327 6.2. High preference by caller to receive sign language and lower 328 preference for text. 330 v=0 332 o=Laura 289083124 289083124 IN IP4 two.example.com 334 c=IN IP4 233.252.0.1/127 335 t=0 0 337 a=group:HLPR 3 2 339 m=audio 30000 RTP/AVP 0 341 a=mid:1 343 m=text 30002 RTP/AVP 98 97 345 a=mid:2 347 m=video 30004 RTP/AVP 34 349 a=mid:3 351 Note that also the audio media needs to include a 'mid' attribute 352 even when it is not included in any grouping for the grouping to be 353 valid. 355 An answer can confirm that sign language will be sent in the video 356 media. 358 v=0 360 o=Laura 289083124 289083124 IN IP4 two.example.com 362 c=IN IP4 233.252.0.1/127 364 t=0 0 366 a=group:HLPS 3 368 m=audio 30000 RTP/AVP 0 370 a=mid:1 372 m=text 30002 RTP/AVP 98 97 374 a=mid:2 376 m=video 30004 RTP/AVP 34 378 a=mid:3 380 7. Acknowledgements 382 - 384 8. IANA Considerations 386 IANA is kindly requested to register the following semantics in the 387 "Semantics for the "group" SDP Attribute" registry under SDP 388 Parameters: 390 Semantics Token Reference 392 ---------------------------------- ----- --------- 394 Human Language Simultaneous Send HLSS TBD: THIS DOCUMENT 396 Human Language Simultaneous Receive HLSS TBD: THIS DOCUMENT 398 Human Language Preference Send HLPS TBD: THIS DOCUMENT 400 Human Language Preference Receive HLPR TBD: THIS DOCUMENT 402 9. Security Considerations 404 Modality preference information may belong to the kind of sensitive 405 user information that some users do not want to be presented to 406 anyone. Measures for protection against unauthorized access to the 407 modality preference information should therefore be prepared and 408 activated when so required. Intended callees should be regarded to 409 be authorized to access the callers modality preference information. 410 The modality preference information should be treated with similar 411 security and privacy measures as other user information such as 412 addresses and language preferences. 414 10. Changes from earlier versions 416 RFC EDITOR: Please remove this section prior to publication. 418 10.1. Changes from draft-hellstrom-slim-modality-grouping-00 to draft- 419 hellstrom-slim-modality-grouping-01 421 Corrections of some spelling mistakes. 423 Simplification of some sentences. 425 10.2. Changes from draft-hellstrom-language-grouping-00 to draft- 426 hellstrom-slim-modality-grouping-00 428 Changed name to indicate that this draft has relations to the IETF 429 SLIM WG. 431 Shortened abstract. 433 changed to more polite IANA considerations. 435 Introduced a section with changes from earlier versions. 437 11. References 439 11.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 447 with Session Description Protocol (SDP)", RFC 3264, 448 DOI 10.17487/RFC3264, June 2002, 449 . 451 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 452 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 453 July 2006, . 455 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 456 Protocol (SDP) Grouping Framework", RFC 5888, 457 DOI 10.17487/RFC5888, June 2010, 458 . 460 11.2. Informative References 462 [I-D.ietf-slim-negotiating-human-language] 463 Gellens, R., "Negotiating Human Language in Real-Time 464 Communications", draft-ietf-slim-negotiating-human- 465 language-19 (work in progress), December 2017. 467 Author's Address 468 Gunnar Hellstrom 469 Omnitor 470 Hammarby Fabriksvag 23 471 Stockholm SE-120 30 472 Sweden 474 Phone: +46 708 204 288 475 Email: gunnar.hellstrom@omnitor.se