1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 8373 Core Technology Consulting
Category: Standards Track May 2018
ISSN: 2070-1721
<span class="h1">Negotiating Human Language in Real-Time Communications</span>
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8373">https://www.rfc-editor.org/info/rfc8373</a>.
<span class="grey">Gellens Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Applicability . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Desired Semantics . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. The Existing 'lang' Attribute . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. The 'hlang-send' and 'hlang-recv' Attributes . . . . . . <a href="#page-5">5</a>
<a href="#section-5.2">5.2</a>. No Language in Common . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. Usage Notes . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.4">5.4</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. att-field Subregistry of SDP Parameters . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Warning Codes Subregistry of SIP Parameters . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. Privacy Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<span class="grey">Gellens Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
A mutually comprehensible language is helpful for human
communication. This document addresses the negotiation of human
language and media modality (spoken, signed, or written) in real-time
communications. A companion document [<a href="./rfc8255" title=""Multiple Language Content Type"">RFC8255</a>] addresses language
selection in email.
Unless the caller and callee know each other or there is contextual
or out-of-band information from which the language(s) and media
modalities can be determined, there is a need for spoken, signed, or
written languages to be negotiated based on the caller's needs and
the callee's capabilities. This need applies to both emergency and
non-emergency calls. An example of a non-emergency call is when a
caller contacts a company call center; an emergency call typically
involves a caller contacting a Public Safety Answering Point (PSAP).
In such scenarios, it is helpful for the caller to be able to
indicate preferred signed, written, and/or spoken languages and for
the callee to be able to indicate its capabilities; this allows the
call to proceed using the language(s) and media forms supported by
both.
For various reasons, including the ability to establish multiple
streams using different media (i.e., voice, text, and/or video), it
makes sense to use a per-stream negotiation mechanism known as the
Session Description Protocol (SDP). Utilizing SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] enables
the solution described in this document to be applied to all
interactive communications negotiated using SDP, in emergency as well
as non-emergency scenarios.
By treating language as another SDP attribute that is negotiated
along with other aspects of a media stream, it becomes possible to
accommodate a range of users' needs and called-party facilities. For
example, some users may be able to speak several languages but have a
preference. Some called parties may support some of those languages
internally but require the use of a translation service for others,
or they may have a limited number of call takers able to use certain
languages. Another example would be a user who is able to speak but
is deaf or hard of hearing and desires a voice stream to send spoken
language plus a text stream to receive written language. Making
language a media attribute allows standard session negotiation to
handle this by providing the information and mechanism for the
endpoints to make appropriate decisions.
The term "negotiation" is used here rather than "indication" because
human language (spoken/written/signed) can be negotiated in the same
manner as media (audio/text/video) and codecs. For example, if we
think of a user calling an airline reservation center, the user may
<span class="grey">Gellens Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
be able to use a set of languages, perhaps with preferences for one
or a few, while the airline reservation center may support a fixed
set of languages. Negotiation should select the user's most
preferred language that is supported by the call center. Both sides
should be aware of which language was negotiated.
In the offer/answer model used here, the offer contains a set of
languages per media (and direction) that the offerer is capable of
using, and the answer contains one language per media (and direction)
that the answerer will support. Supporting languages and/or
modalities can require taking extra steps, such as bridging external
translation or relay resources into the call or having a call handled
by an agent who speaks a requested language and/or has the ability to
use a requested modality. The answer indicates the media and
languages that the answerer is committing to support (possibly after
additional steps have been taken). This model also provides
knowledge so both ends know what has been negotiated. Note that
additional steps required to support the indicated languages or
modalities may or may not be in place in time for any early media.
Since this is a protocol mechanism, the user equipment (UE) client
needs to know the user's preferred languages; while this document
does not address how clients determine this, reasonable techniques
could include a configuration mechanism with a default of the
language of the user interface. In some cases, a UE client could tie
language and media preferences, such as a preference for a video
stream using a signed language and/or a text or audio stream using a
written/spoken language.
This document does not address user interface (UI) issues, such as if
or how a UE client informs a user about the result of language and
media negotiation.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Applicability</span>
Within this document, it is assumed that the negotiating endpoints
have already been determined so that a per-stream negotiation based
on SDP can proceed.
When setting up interactive communication sessions, it is necessary
to route signaling messages to the appropriate endpoint(s). This
document does not address the problem of language-based routing.
<span class="grey">Gellens Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Desired Semantics</span>
The desired solution is a media attribute (preferably per direction)
that may be used within an offer to indicate the preferred
language(s) of each (direction of a) media stream and within an
answer to indicate the accepted language. When multiple languages
are included for a media stream within an offer, the languages are
listed in order of preference (most preferred first).
Note that negotiating multiple simultaneous languages within a media
stream is out of scope of this document.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The Existing 'lang' Attribute</span>
<a href="./rfc4566">RFC 4566</a> [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] specifies an attribute 'lang' that is similar to
what is needed here but is not sufficiently specific or flexible for
the needs of this document. In addition, 'lang' is not mentioned in
[<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>], and there are no known implementations in SIP. Further,
it is useful to be able to specify language per direction (sending
and receiving). This document therefore defines two new attributes.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Solution</span>
An SDP attribute (per direction) seems the natural choice to
negotiate human language of an interactive media stream, using the
language tags of [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. The 'hlang-send' and 'hlang-recv' Attributes</span>
This document defines two media-level attributes: 'hlang-send' and
'hlang-recv' (registered in <a href="#section-6">Section 6</a>). Both start with 'hlang',
short for "human language". These attributes are used to negotiate
which human language is selected for use in (each direction of) each
interactive media stream. (Note that not all streams will
necessarily be used.) Each can appear for media streams in offers
and answers.
In an offer, the 'hlang-send' value is a list of one or more
language(s) the offerer is willing to use when sending using the
media, and the 'hlang-recv' value is a list of one or more
<span class="grey">Gellens Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
language(s) the offerer is willing to use when receiving using the
media. The list of languages is in preference order (first is most
preferred). When a media is intended for interactive communication
in only one direction (e.g., a user in France with difficulty
speaking but able to hear who indicates a desire to receive French
using audio and send French using text), either 'hlang-send' or
'hlang-recv' MAY be omitted. Note that the media can still be useful
in both directions. When a media is not primarily intended for
language (for example, a video or audio stream intended for
background only), both SHOULD be omitted. Otherwise, both SHOULD
have the same value. Note that specifying different languages for
each direction (as opposed to the same, or essentially the same,
language in different modalities) can make it difficult to complete
the call (e.g., specifying a desire to send audio in Hungarian and
receive audio in Portuguese).
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').
In an offer, each value MUST be a list of one or more language tags
per [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>], separated by white space. In an answer, each value MUST
be one language tag per [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>]. [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>] describes mechanisms for
matching language tags. Note that <a href="./rfc5646#section-4.1">Section 4.1 of RFC 5646</a> [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>]
advises to "tag content wisely" and not include unnecessary subtags.
When placing an emergency call, and in any other case where the
language cannot be inferred from context, each OFFERed media stream
primarily intended for human language communication SHOULD specify
the 'hlang-send' and/or 'hlang-recv' attributes for the direction(s)
intended for interactive communication.
Clients acting on behalf of end users are expected to set one or both
of the 'hlang-send' and 'hlang-recv' attributes on each OFFERed media
stream primarily intended for human communication when placing an
outgoing session, and either ignore or take into consideration the
attributes when receiving incoming calls, based on local
configuration and capabilities. Systems acting on behalf of call
centers and PSAPs are expected to take the attributes into account
when processing inbound calls.
Note that media and language negotiation might result in more media
streams being accepted than are needed by the users (e.g., if more
preferred and less preferred combinations of media and language are
all accepted). This is not a problem.
<span class="grey">Gellens Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. No Language in Common</span>
A consideration regarding the ability to negotiate language is
whether the call proceeds or fails if the callee does not support any
of the languages requested by the caller. This document does not
mandate either behavior.
When a call is rejected due to lack of any language in common, the
SIP response has SIP response code 488 (Not Acceptable Here) or 606
(Not Acceptable) [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] and a Warning header field [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] with
a warning code of 308 and warning text indicating that there are no
mutually supported languages; the warning text SHOULD also contain
the supported languages and media.
Example:
Warning: 308 proxy.example.com "Incompatible language
specification: Requested languages not supported. Supported
languages are: es, en; supported media are: audio, text."
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Usage Notes</span>
A sign-language tag with a video media stream is interpreted as an
indication for sign language in the video stream. A non-sign-
language tag with a text media stream is interpreted as an indication
for written language in the text stream. A non-sign-language tag
with an audio media stream is interpreted as an indication for spoken
language in the audio stream.
This document does not define any other use for language tags in
video media (such as how to indicate visible captions in the video
stream).
This document does not define the use of sign-language tags in text
or audio media.
In the IANA registry for language subtags per [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>], a language
subtag with a Type field "extlang" combined with a Prefix field value
"sgn" indicates a sign-language tag. The absence of such "sgn"
prefix indicates a non-sign-language tag.
This document does not define the use of language tags in media other
than interactive streams of audio, video, and text (such as "message"
or "application"). Such use could be supported by future work or by
application agreement.
<span class="grey">Gellens Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Examples</span>
Some examples are shown below. For clarity, only the most directly
relevant portions of the SDP block are shown.
An offer or answer indicating spoken English both ways:
m=audio 49170 RTP/AVP 0
a=hlang-send:en
a=hlang-recv:en
An offer indicating American Sign Language both ways:
m=video 51372 RTP/AVP 31 32
a=hlang-send:ase
a=hlang-recv:ase
An offer requesting spoken Spanish both ways (most preferred), spoken
Basque both ways (second preference), or spoken English both ways
(third preference):
m=audio 49250 RTP/AVP 20
a=hlang-send:es eu en
a=hlang-recv:es eu en
An answer to the above offer indicating spoken Spanish both ways:
m=audio 49250 RTP/AVP 20
a=hlang-send:es
a=hlang-recv:es
An alternative answer to the above offer indicating spoken Italian
both ways (as the callee does not support any of the requested
languages but chose to proceed with the call):
m=audio 49250 RTP/AVP 20
a=hlang-send:it
a=hlang-recv:it
An offer or answer indicating written Greek both ways:
m=text 45020 RTP/AVP 103 104
a=hlang-send:gr
a=hlang-recv:gr
An offer requesting the following media streams: video for the caller
to send using Argentine Sign Language, text for the caller to send
using written Spanish (most preferred) or written Portuguese, and
<span class="grey">Gellens Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
audio for the caller to receive spoken Spanish (most preferred) or
spoken Portuguese:
m=video 51372 RTP/AVP 31 32
a=hlang-send:aed
m=text 45020 RTP/AVP 103 104
a=hlang-send:sp pt
m=audio 49250 RTP/AVP 20
a=hlang-recv:sp pt
An answer for the above offer, indicating text in which the callee
will receive written Spanish and audio in which the callee will send
spoken Spanish. (The answering party has no video capability):
m=video 0 RTP/AVP 31 32
m=text 45020 RTP/AVP 103 104
a=hlang-recv:sp
m=audio 49250 RTP/AVP 20
a=hlang-send:sp
An offer requesting the following media streams: text for the caller
to send using written English (most preferred) or written Spanish,
audio for the caller to receive spoken English (most preferred) or
spoken Spanish, and supplemental video:
m=text 45020 RTP/AVP 103 104
a=hlang-send:en sp
m=audio 49250 RTP/AVP 20
a=hlang-recv:en sp
m=video 51372 RTP/AVP 31 32
An answer for the above offer, indicating text in which the callee
will receive written Spanish, audio in which the callee will send
spoken Spanish, and supplemental video:
m=text 45020 RTP/AVP 103 104
a=hlang-recv:sp
m=audio 49250 RTP/AVP 20
a=hlang-send:sp
m=video 51372 RTP/AVP 31 32
<span class="grey">Gellens Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
Note that, even though the examples show the same (or essentially the
same) language being used in both directions (even when the modality
differs), there is no requirement that this be the case. However, in
practice, doing so is likely to increase the chances of successful
matching.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. att-field Subregistry of SDP Parameters</span>
The syntax in this section uses ABNF per <a href="./rfc5234">RFC 5234</a> [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
IANA has added two entries to the "att-field (media level only)"
subregistry of the "Session Description Protocol (SDP) Parameters"
registry.
The first entry is for 'hlang-recv':
Attribute Name: hlang-recv
Long-Form English Name: human language receive
Contact Name: Randall Gellens
Contact Email Address: rg+ietf@coretechnologyconsulting.com
Attribute Value: hlang-value
Attribute Syntax:
hlang-value = hlang-offv / hlang-ansv
; hlang-offv used in offers
; hlang-ansv used in answers
hlang-offv = Language-Tag *( SP Language-Tag )
; Language-Tag as defined in [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>]
SP = 1*" " ; one or more space (%x20) characters
hlang-ansv = Language-Tag
Attribute Semantics: Described in <a href="./rfc8373#section-5.1">Section 5.1 of RFC 8373</a>
Usage Level: media
Mux Category: NORMAL
Charset Dependent: No
Purpose: See <a href="./rfc8373#section-5.1">Section 5.1 of RFC 8373</a>
O/A Procedures: See <a href="./rfc8373#section-5.1">Section 5.1 of RFC 8373</a>
Reference: <a href="./rfc8373">RFC 8373</a>
<span class="grey">Gellens Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
The second entry is for 'hlang-send':
Attribute Name: hlang-send
Long-Form English Name: human language send
Contact Name: Randall Gellens
Contact Email Address: rg+ietf@coretechnologyconsulting.com
Attribute Value: hlang-value
Attribute Syntax:
hlang-value = hlang-offv / hlang-ansv
Attribute Semantics: Described in <a href="./rfc8373#section-5.1">Section 5.1 of RFC 8373</a>
Usage Level: media
Mux Category: NORMAL
Charset Dependent: No
Purpose: See <a href="./rfc8373#section-5.1">Section 5.1 of RFC 8373</a>
O/A Procedures: See <a href="./rfc8373#section-5.1">Section 5.1 of RFC 8373</a>
Reference: <a href="./rfc8373">RFC 8373</a>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Warning Codes Subregistry of SIP Parameters</span>
IANA has added the value 308 to the "Warning Codes (warn-codes)"
subregistry of the "Session Initiation Protocol (SIP) Parameters"
registry. (The value lies within the range allocated for indicating
problems with keywords in the session description.) The reference is
to this document. The warn text is "Incompatible language
specification: Requested languages not supported. Supported
languages are [list of supported languages]; supported media are:
[list of supported media]."
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The Security Considerations of [<a href="#ref-BCP47" title=""Matching of Language Tags"">BCP47</a>] apply here. An attacker with
the ability to modify signaling could prevent a call from succeeding
by altering any of several crucial elements, including the
'hlang-send' or 'hlang-recv' values. <a href="./rfc5069">RFC 5069</a> [<a href="./rfc5069" title=""Security Threats and Requirements for Emergency Call Marking and Mapping"">RFC5069</a>] discusses
such threats. Use of TLS or IPsec can protect against such threats.
Emergency calls are of particular concern; <a href="./rfc6881">RFC 6881</a> [<a href="./rfc6881" title=""Best Current Practice for Communications Services in Support of Emergency Calling"">RFC6881</a>], which
is specific to emergency calls, mandates use of TLS or IPsec (in
ED-57/SP-30).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Privacy Considerations</span>
Language and media information can suggest a user's nationality,
background, abilities, disabilities, etc.
<span class="grey">Gellens Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-BCP47">BCP47</a>] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", <a href="https://www.rfc-editor.org/bcp/bcp47">BCP 47</a>, <a href="./rfc4647">RFC 4647</a>, DOI 10.17487/RFC4647, September
2006.
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", <a href="https://www.rfc-editor.org/bcp/bcp47">BCP 47</a>, <a href="./rfc5646">RFC 5646</a>, DOI 10.17487/RFC5646,
September 2009.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
DOI 10.17487/RFC3261, June 2002,
<<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>>.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, DOI 10.17487/RFC4566,
July 2006, <<a href="https://www.rfc-editor.org/info/rfc4566">https://www.rfc-editor.org/info/rfc4566</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", <a href="./rfc3264">RFC 3264</a>,
DOI 10.17487/RFC3264, June 2002,
<<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>>.
[<a id="ref-RFC5069">RFC5069</a>] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", <a href="./rfc5069">RFC 5069</a>,
DOI 10.17487/RFC5069, January 2008,
<<a href="https://www.rfc-editor.org/info/rfc5069">https://www.rfc-editor.org/info/rfc5069</a>>.
<span class="grey">Gellens Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8373">RFC 8373</a> Negotiating Human Language May 2018</span>
[<a id="ref-RFC6881">RFC6881</a>] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling",
<a href="https://www.rfc-editor.org/bcp/bcp181">BCP 181</a>, <a href="./rfc6881">RFC 6881</a>, DOI 10.17487/RFC6881, March 2013,
<<a href="https://www.rfc-editor.org/info/rfc6881">https://www.rfc-editor.org/info/rfc6881</a>>.
[<a id="ref-RFC8255">RFC8255</a>] Tomkinson, N. and N. Borenstein, "Multiple Language
Content Type", <a href="./rfc8255">RFC 8255</a>, DOI 10.17487/RFC8255, October
2017, <<a href="https://www.rfc-editor.org/info/rfc8255">https://www.rfc-editor.org/info/rfc8255</a>>.
Acknowledgements
Many thanks to Bernard Aboba, Harald Alvestrand, Flemming Andreasen,
Francois Audet, Eric Burger, Keith Drage, Doug Ewell, Christian
Groves, Andrew Hutton, Hadriel Kaplan, Ari Keranen, John Klensin,
Mirja Kuhlewind, Paul Kyzivat, John Levine, Alexey Melnikov, Addison
Phillips, James Polk, Eric Rescorla, Pete Resnick, Alvaro Retana,
Natasha Rooney, Brian Rosen, Peter Saint-Andre, and Dale Worley for
their reviews, corrections, suggestions, and participation in email
and in-person discussions.
Contributors
Gunnar Hellstrom deserves special mention for his reviews and
assistance.
Author's Address
Randall Gellens
Core Technology Consulting
Email: rg+ietf@coretechnologyconsulting.com
URI: <a href="http://www.coretechnologyconsulting.com">http://www.coretechnologyconsulting.com</a>
Gellens Standards Track [Page 13]
</pre>
|
