idnits 2.17.1 draft-hellstrom-language-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 (June 10, 2017) is 2505 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-10 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 June 10, 2017 5 Expires: December 12, 2017 7 Human Language Modality Grouping Semantics in Session Description 8 Protocol 9 draft-hellstrom-language-grouping-00 11 Abstract 13 In a real-time communication session, there may be a need or 14 preference for receiving the same content in two or more simultaneous 15 modalities. There may also be a need to prioritize which media to 16 use for language communications. This document defines the semantics 17 for grouping media in the Session Description Protocol (SDP) 18 containing human languages in order to assign their relative priority 19 and also grouping media that are desired to be received together. 20 The semantics defined in this document are to be used with the SDP 21 Grouping Framework. Applications are for example a possibility to 22 indicate when a sign language is most desired, but written language 23 an acceptable lower rated alternative, offered for the other party to 24 select between. Applications are also for indication of need for 25 both spoken and written content in a real-time call (captioning) 26 together, or provision of both spoken language original and sign 27 language interpretation of the original language together in a real- 28 time session. These indications are specified for the sending and 29 receiving direction separately. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 12, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Requirements for Modality Grouping . . . . . . . . . . . . . 4 68 3.1. Simultaneous Use of Different Modalities . . . . . . . . 4 69 3.2. Preference for Language in Different Modality . . . . . . 4 70 4. Modality Grouping . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Simultaneous Use of Different Modalities . . . . . . . . 4 72 4.2. Preference for Language in Different Modality . . . . . . 5 73 5. SDP Offer/Answer Considerations . . . . . . . . . . . . . . . 5 74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Desire by caller to receive both spoken and written 76 language form of media . . . . . . . . . . . . . . . . . 6 77 6.2. High preference by caller to receive sign language and 78 lower preference for text. . . . . . . . . . . . . . . . 7 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 10.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 In certain applications it is of interest to indicate a need for, or 90 the availability of, transformed version of the contents of a media 91 stream in another media, while still also providing the original. 93 The application of this indication may for example be for rapid 94 subtitling of speech either manually or automatically. It may also 95 be sign language interpretation of speech, or spoken interpretation 96 of sign language when both the original and the interpretation is 97 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 mechaism 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 not only indicate alternative languages and 119 modalities for the communication directions in the session, but also 120 indicate preference for specific modalities per direction provides 121 the opportunity to more exactly describe the desired language 122 communication for a session, while still providing information about 123 less preferred alternatives. This specification defines a mechanism 124 for indicating modality preference based on the Session Description 125 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 laanguage capability on a higher level. Some persons with 138 disabilities may strongly prefer to conduct a written conversation, 139 while still wanting to express that a spoken conversation is possible 140 as a last resort. Many other situations exist in the media-rich 141 communication environment when the media preference indication is of 142 value for a smooth initiation of a real-time session. 144 The mechanisms for specifying simultaneous use of language in 145 different modalities and preferece between modalities may be combined 146 with a mechanism for specifying language use in media. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Requirements for Modality Grouping 156 3.1. Simultaneous Use of Different Modalities 158 The grouping semantics for indication of simultaneous use of 159 different media for different transforms of the same language shall 160 have the ability to indicate: 162 o That the language contents of one media is desired or offered also 163 simultaneously in a transformed form in other media grouped with 164 the first. 166 o The direction of language communication that the indication is 167 valid for; sending or receiving as seen from the party providing 168 the SDP. 170 3.2. Preference for Language in Different Modality 172 The grouping semantics for indication of relative preference between 173 use for language communication in different media and modalities 174 shall have the ability to indicate: 176 o The order of preference for receiving or providing language 177 contents in the media included in a grouping. 179 o The direction of language communication that the indication is 180 valid for; sending or receiving as seen from the party providing 181 the SDP. 183 4. Modality Grouping 185 4.1. Simultaneous Use of Different Modalities 187 The "Human Language Simultaneous Send" (HLSS) and "Human Language 188 Simultaneous Receive" (HLSR) grouping semantics and the SDP "group" 189 attribute defined in [RFC5888] are used to associate media in which 190 it is indicated that different transforms of the same content is 191 either desired to be received by a party or offered for sending by a 192 party. 194 The "a=group:HLSS" semantics SHOULD be used to indicate media 195 grouping for preparedness for sending of same language contents in 196 different transforms in all media included in the group. 198 The "a=group:HLSR" semantics SHOULD be used to indicate media 199 grouping for preference for reception of language contents in 200 different transforms in all media in the group. 202 The HLSS and HLSR semantics MAY be used together with mechanisms for 203 detailing language use in media. One such mechanism is 204 [I-D.ietf-slim-negotiating-human-language]. 206 4.2. Preference for Language in Different Modality 208 The "Human Language Preferred Send" (HLPS) and "Human Language 209 Preferred Receive" (HLSR) grouping semantics and the SDP "group" 210 attribute defined in [RFC5888] are used to associate media among 211 which it is indicated an order of preference for using the media for 212 language contents. The order of preference is that the media 213 identity first in the group has highest preference and the following 214 have lower preference in the same order as they appear in the group 215 definition. 217 The "a=group:HLPS" semantics SHOULD be used to indicate media 218 grouping for preparedness for sending of language contents with 219 preference in the same order as the media identities appear in the 220 group with the first having highest preference. . 222 The "a=group:HLSR" semantics SHOULD be used to indicate media 223 grouping for preference for reception of language contents with 224 preference in the same order as the media identities appear in the 225 group with the first having highest preference. 227 The HLSS and HLSR semantics MAY be used together with mechanisms for 228 detailing language use in media. One such mechanism is 229 [I-D.ietf-slim-negotiating-human-language]. 231 5. SDP Offer/Answer Considerations 233 The following SDP offer/answer considerations according to [RFC3264] 234 apply. 236 An application that understands the received HLSR, HLSS, HLPR or HLPS 237 grouping semantics SHOULD make efforts to satisfy the preferences 238 expressed by the grouping semantic. 240 HLSR, HLSS, HLPR or HLPS grouping semantics corresponding to what the 241 application prefers to receive and what the application is prepared 242 to send, best matching the received preference indications and its 243 own capabilities SHOULD be included in the answer. 245 The offering party SHOULD analyze the answer and make best effort to 246 transmit language contents in media according to the answer. 248 The grouping semantics defined in this document are only informing 249 about language contents disposition in media and SHOULD not be taken 250 as reasons to enable or reject media streams. 252 Media not included in any HLPR or HLPS grouping are assumed to be 253 assigned lower preference for being used for language communication 254 than the ones included in HLPR or HLPS grouping. 256 If the HLSR, HLSS, HLPR or HLPS grouping semantics are used without 257 any further language specifications, video media SHOULD be assumed to 258 be used for sign language. 260 Note that grouping of "m" lines MUST always be requested by the 261 offerer, but never by the answerer. Since SIP provides a two-way SDP 262 exchange, an answerer that requested grouping would not know whether 263 the "group" attribute was accepted by the offerer or not. An 264 answerer that wants to group media lines issues another offer after 265 having responded to the first one (in a re-INVITE, for instance). 267 6. Examples 269 6.1. Desire by caller to receive both spoken and written language form 270 of media 272 v=0 274 o=Laura 289083124 289083124 IN IP4 two.example.com 276 c=IN IP4 233.252.0.1/127 278 t=0 0 280 a=group:HLSR 1 2 282 m=audio 30000 RTP/AVP 0 284 a=mid:1 286 m=text 30002 RTP/AVP 98 97 287 a=mid:2 289 m=video 30004 RTP/AVP 34 291 a=mid:3 293 Note that also the video media needs to include a 'mid' attribute 294 even when it is not included in any grouping for the grouping to be 295 valid. 297 An answer can confirm that both desired media will contain the same 298 language contents. 300 v=0 302 o=Laura 289083124 289083124 IN IP4 two.example.com 304 c=IN IP4 233.252.0.1/127 306 t=0 0 308 a=group:HLSS 1 2 310 m=audio 30000 RTP/AVP 0 312 a=mid:1 314 m=text 30002 RTP/AVP 98 97 316 a=mid:2 318 m=video 30004 RTP/AVP 34 320 a=mid:3 322 6.2. High preference by caller to receive sign language and lower 323 preference for text. 325 v=0 327 o=Laura 289083124 289083124 IN IP4 two.example.com 329 c=IN IP4 233.252.0.1/127 331 t=0 0 333 a=group:HLPR 3 2 334 m=audio 30000 RTP/AVP 0 336 a=mid:1 338 m=text 30002 RTP/AVP 98 97 340 a=mid:2 342 m=video 30004 RTP/AVP 34 344 a=mid:3 346 Note that also the audio media needs to include a 'mid' attribute 347 even when it is not included in any grouping for the grouping to be 348 valid. 350 An answer can confirm that sign language will be sent in the video 351 media. 353 v=0 355 o=Laura 289083124 289083124 IN IP4 two.example.com 357 c=IN IP4 233.252.0.1/127 359 t=0 0 361 a=group:HLPS 3 363 m=audio 30000 RTP/AVP 0 365 a=mid:1 367 m=text 30002 RTP/AVP 98 97 369 a=mid:2 371 m=video 30004 RTP/AVP 34 373 a=mid:3 375 7. Acknowledgements 377 - 379 8. IANA Considerations 381 This document registers the following semantics with IANA in the 382 "Semantics for the "group" SDP Attribute" registry under SDP 383 Parameters: 385 Semantics Token Reference 387 ---------------------------------- ----- --------- 389 Human Language Simultaneous Send HLSS TBD: THIS DOCUMENT 391 Human Language Simultaneous Receive HLSS TBD: THIS DOCUMENT 393 Human Language Preference Send HLPS TBD: THIS DOCUMENT 395 Human Language Preference Receive HLPR TBD: THIS DOCUMENT 397 9. Security Considerations 399 Modality preference information may belong to the kind of sensitive 400 user information that some users do not want to be presented to 401 anyone. Measures for protection against unauthorized access to the 402 modality preference information should therefore be prepared and 403 activated when so required. Intended callees should be regarded to 404 be authorized to access the callers modality preference information. 405 The modality preference information should be treated with similar 406 security and privacy measures as other user information such as 407 addresses and language preferences. 409 10. References 411 10.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 419 with Session Description Protocol (SDP)", RFC 3264, 420 DOI 10.17487/RFC3264, June 2002, 421 . 423 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 424 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 425 July 2006, . 427 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 428 Protocol (SDP) Grouping Framework", RFC 5888, 429 DOI 10.17487/RFC5888, June 2010, 430 . 432 10.2. Informative References 434 [I-D.ietf-slim-negotiating-human-language] 435 Gellens, R., "Negotiating Human Language in Real-Time 436 Communications", draft-ietf-slim-negotiating-human- 437 language-10 (work in progress), May 2017. 439 Author's Address 441 Gunnar Hellstrom 442 Omnitor 443 Hammarby Fabriksvag 23 444 Stockholm SE-120 30 445 Sweden 447 Phone: +46 708 204 288 448 Email: gunnar.hellstrom@omnitor.se