idnits 2.17.1 draft-hellstrom-slim-modality-grouping-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The grouping semantics defined in this document are only informing about language contents disposition in media and SHOULD not be taken as reasons to enable or reject media streams. -- The document date (July 3, 2017) is 2487 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-12 Summary: 1 error (**), 0 flaws (~~), 3 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 July 3, 2017 5 Expires: January 4, 2018 7 Human Language Modality Grouping Semantics in Session Description 8 Protocol 9 draft-hellstrom-slim-modality-grouping-00 11 Abstract 13 When setting up a real-time communication session, there may be a 14 need to indicate priority for which media to use for language 15 communications or a need to indicate preference for receiving the 16 same language content simultaneously in two modalities. This 17 document defines the semantics for grouping media for such purposes 18 in the Session Description Protocol (SDP). The semantics defined in 19 this document are based on the SDP Grouping Framework. Applications 20 are for example negotiation the most suitable common modality or 21 modalities for language communications in a real-time session. The 22 indications are specified for the sending and receiving direction 23 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 http://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 January 4, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 10. Changes from earlier versions . . . . . . . . . . . . . . . . 9 77 10.1. Changes from draft-hellstrom-language-grouping-00 to 78 draft-hellstrom-slim-modality-grouping-00 . . . . . . . 9 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 11.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 In certain applications it is of interest to indicate a need for, or 87 the availability of, transformed version of the contents of a media 88 stream in another media, while still also providing the original. 90 The application of this indication may for example be for rapid 91 subtitling of speech either manually or automatically. It may also 92 be sign language interpretation of speech, or spoken interpretation 93 of sign language when both the original and the interpretation is 94 delivered to the user. 96 This specification defines an indication that language contents in 97 one modality is desired simultaneously with a different modality. 98 The mechaism used is based on the Session Description Protocol (SDP) 99 Grouping Framework [RFC5888] and used with SDP [RFC4566]. The same 100 indication is used for indication of preparedness to send language 101 contents in one modality simultaneously with same content in a 102 different modality. 104 When starting a conversation in a media-rich environment, the users 105 may have very specific preferences for using one modality (spoken, 106 written or signed) over other possible but less preferred modalities. 107 In traditional call establishment, it is the answering part who is 108 expected to start the conversation by a greeting. In the media-rich 109 environment, the modality and language of this greeting sets the 110 expectations for what modality and language to mainly use in the 111 session. Deviation from this initial expectation is usually possible 112 during the session by mutual agreement between the participants, but 113 may be time consuming and cause uncertainty. 115 A way for the parties to not only indicate alternative languages and 116 modalities for the communication directions in the session, but also 117 indicate preference for specific modalities per direction provides 118 the opportunity to more exactly describe the desired language 119 communication for a session, while still providing information about 120 less preferred alternatives. This specification defines a mechanism 121 for indicating modality preference based on the Session Description 122 Protocol (SDP) Grouping Framework [RFC5888]. 124 The expected application area is wide. By old tradition, the most 125 common modality for real-time interaction is spoken communication. 126 In some settings, e.g. where silence is required, it may be desirable 127 to express a preference for using written communication, while still 128 leaving a possibility open for traditional spoken communication by an 129 indication on lower preference level. For persons having full 130 ability to both use sign language and spoken language, but not 131 wanting to force the other party to bring in a sign language 132 interpreter in the call, it may be of importance to be able to 133 indicate the sign language capability on a lower preference level and 134 the spoken laanguage capability on a higher level. Some persons with 135 disabilities may strongly prefer to conduct a written conversation, 136 while still wanting to express that a spoken conversation is possible 137 as a last resort. Many other situations exist in the media-rich 138 communication environment when the media preference indication is of 139 value for a smooth initiation of a real-time session. 141 The mechanisms for specifying simultaneous use of language in 142 different modalities and preferece between modalities may be combined 143 with a mechanism for specifying language use in media. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. Requirements for Modality Grouping 153 3.1. Simultaneous Use of Different Modalities 155 The grouping semantics for indication of simultaneous use of 156 different media for different transforms of the same language shall 157 have the ability to indicate: 159 o That the language contents of one media is desired or offered also 160 simultaneously in a transformed form in other media grouped with 161 the first. 163 o The direction of language communication that the indication is 164 valid for; sending or receiving as seen from the party providing 165 the SDP. 167 3.2. Preference for Language in Different Modality 169 The grouping semantics for indication of relative preference between 170 use for language communication in different media and modalities 171 shall have the ability to indicate: 173 o The order of preference for receiving or providing language 174 contents in the media included in a grouping. 176 o The direction of language communication that the indication is 177 valid for; sending or receiving as seen from the party providing 178 the SDP. 180 4. Modality Grouping 182 4.1. Simultaneous Use of Different Modalities 184 The "Human Language Simultaneous Send" (HLSS) and "Human Language 185 Simultaneous Receive" (HLSR) grouping semantics and the SDP "group" 186 attribute defined in [RFC5888] are used to associate media in which 187 it is indicated that different transforms of the same content is 188 either desired to be received by a party or offered for sending by a 189 party. 191 The "a=group:HLSS" semantics SHOULD be used to indicate media 192 grouping for preparedness for sending of same language contents in 193 different transforms in all media included in the group. 195 The "a=group:HLSR" semantics SHOULD be used to indicate media 196 grouping for preference for reception of language contents in 197 different transforms in all media in the group. 199 The HLSS and HLSR semantics MAY be used together with mechanisms for 200 detailing language use in media. One such mechanism is 201 [I-D.ietf-slim-negotiating-human-language]. 203 4.2. Preference for Language in Different Modality 205 The "Human Language Preferred Send" (HLPS) and "Human Language 206 Preferred Receive" (HLSR) grouping semantics and the SDP "group" 207 attribute defined in [RFC5888] are used to associate media among 208 which it is indicated an order of preference for using the media for 209 language contents. The order of preference is that the media 210 identity first in the group has highest preference and the following 211 have lower preference in the same order as they appear in the group 212 definition. 214 The "a=group:HLPS" semantics SHOULD be used to indicate media 215 grouping for preparedness for sending of language contents with 216 preference in the same order as the media identities appear in the 217 group with the first having highest preference. . 219 The "a=group:HLSR" semantics SHOULD be used to indicate media 220 grouping for preference for reception of language contents with 221 preference in the same order as the media identities appear in the 222 group with the first having highest preference. 224 The HLSS and HLSR semantics MAY be used together with mechanisms for 225 detailing language use in media. One such mechanism is 226 [I-D.ietf-slim-negotiating-human-language]. 228 5. SDP Offer/Answer Considerations 230 The following SDP offer/answer considerations according to [RFC3264] 231 apply. 233 An application that understands the received HLSR, HLSS, HLPR or HLPS 234 grouping semantics SHOULD make efforts to satisfy the preferences 235 expressed by the grouping semantic. 237 HLSR, HLSS, HLPR or HLPS grouping semantics corresponding to what the 238 application prefers to receive and what the application is prepared 239 to send, best matching the received preference indications and its 240 own capabilities SHOULD be included in the answer. 242 The offering party SHOULD analyze the answer and make best effort to 243 transmit language contents in media according to the answer. 245 The grouping semantics defined in this document are only informing 246 about language contents disposition in media and SHOULD not be taken 247 as reasons to enable or reject media streams. 249 Media not included in any HLPR or HLPS grouping are assumed to be 250 assigned lower preference for being used for language communication 251 than the ones included in HLPR or HLPS grouping. 253 If the HLSR, HLSS, HLPR or HLPS grouping semantics are used without 254 any further language specifications, video media SHOULD be assumed to 255 be used for sign language. 257 Note that grouping of "m" lines MUST always be requested by the 258 offerer, but never by the answerer. Since SIP provides a two-way SDP 259 exchange, an answerer that requested grouping would not know whether 260 the "group" attribute was accepted by the offerer or not. An 261 answerer that wants to group media lines issues another offer after 262 having responded to the first one (in a re-INVITE, for instance). 264 6. Examples 266 6.1. Desire by caller to receive both spoken and written language form 267 of media 269 v=0 271 o=Laura 289083124 289083124 IN IP4 two.example.com 273 c=IN IP4 233.252.0.1/127 275 t=0 0 277 a=group:HLSR 1 2 279 m=audio 30000 RTP/AVP 0 281 a=mid:1 283 m=text 30002 RTP/AVP 98 97 285 a=mid:2 286 m=video 30004 RTP/AVP 34 288 a=mid:3 290 Note that also the video media needs to include a 'mid' attribute 291 even when it is not included in any grouping for the grouping to be 292 valid. 294 An answer can confirm that both desired media will contain the same 295 language contents. 297 v=0 299 o=Laura 289083124 289083124 IN IP4 two.example.com 301 c=IN IP4 233.252.0.1/127 303 t=0 0 305 a=group:HLSS 1 2 307 m=audio 30000 RTP/AVP 0 309 a=mid:1 311 m=text 30002 RTP/AVP 98 97 313 a=mid:2 315 m=video 30004 RTP/AVP 34 317 a=mid:3 319 6.2. High preference by caller to receive sign language and lower 320 preference for text. 322 v=0 324 o=Laura 289083124 289083124 IN IP4 two.example.com 326 c=IN IP4 233.252.0.1/127 328 t=0 0 330 a=group:HLPR 3 2 332 m=audio 30000 RTP/AVP 0 333 a=mid:1 335 m=text 30002 RTP/AVP 98 97 337 a=mid:2 339 m=video 30004 RTP/AVP 34 341 a=mid:3 343 Note that also the audio media needs to include a 'mid' attribute 344 even when it is not included in any grouping for the grouping to be 345 valid. 347 An answer can confirm that sign language will be sent in the video 348 media. 350 v=0 352 o=Laura 289083124 289083124 IN IP4 two.example.com 354 c=IN IP4 233.252.0.1/127 356 t=0 0 358 a=group:HLPS 3 360 m=audio 30000 RTP/AVP 0 362 a=mid:1 364 m=text 30002 RTP/AVP 98 97 366 a=mid:2 368 m=video 30004 RTP/AVP 34 370 a=mid:3 372 7. Acknowledgements 374 - 376 8. IANA Considerations 378 IANA is kindly requested to register the following semantics in the 379 "Semantics for the "group" SDP Attribute" registry under SDP 380 Parameters: 382 Semantics Token Reference 384 ---------------------------------- ----- --------- 386 Human Language Simultaneous Send HLSS TBD: THIS DOCUMENT 388 Human Language Simultaneous Receive HLSS TBD: THIS DOCUMENT 390 Human Language Preference Send HLPS TBD: THIS DOCUMENT 392 Human Language Preference Receive HLPR TBD: THIS DOCUMENT 394 9. Security Considerations 396 Modality preference information may belong to the kind of sensitive 397 user information that some users do not want to be presented to 398 anyone. Measures for protection against unauthorized access to the 399 modality preference information should therefore be prepared and 400 activated when so required. Intended callees should be regarded to 401 be authorized to access the callers modality preference information. 402 The modality preference information should be treated with similar 403 security and privacy measures as other user information such as 404 addresses and language preferences. 406 10. Changes from earlier versions 408 RFC EDITOR: Please remove this section prior to publication. 410 10.1. Changes from draft-hellstrom-language-grouping-00 to draft- 411 hellstrom-slim-modality-grouping-00 413 Changed name to indicate that this draft has relations to the IETF 414 SLIM WG. 416 Shortened abstract. 418 changed to more polite IANA considerations. 420 Introduced a section with changes from earlier versions. 422 11. References 424 11.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 432 with Session Description Protocol (SDP)", RFC 3264, 433 DOI 10.17487/RFC3264, June 2002, 434 . 436 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 437 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 438 July 2006, . 440 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 441 Protocol (SDP) Grouping Framework", RFC 5888, 442 DOI 10.17487/RFC5888, June 2010, 443 . 445 11.2. Informative References 447 [I-D.ietf-slim-negotiating-human-language] 448 Gellens, R., "Negotiating Human Language in Real-Time 449 Communications", draft-ietf-slim-negotiating-human- 450 language-12 (work in progress), July 2017. 452 Author's Address 454 Gunnar Hellstrom 455 Omnitor 456 Hammarby Fabriksvag 23 457 Stockholm SE-120 30 458 Sweden 460 Phone: +46 708 204 288 461 Email: gunnar.hellstrom@omnitor.se