idnits 2.17.1
draft-hoschka-smilsdp-00.txt:
** The Abstract section seems to be numbered
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-27) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) 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.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 740 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 27 instances of too long lines in the document, the longest
one being 7 characters in excess of 72.
** The abstract seems to contain references ([46], [47]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The "Author's Address" (or "Authors' Addresses") section title is
misspelled.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (January 1, 1999) is 9248 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET DRAFT
3 draft-hoschka-smilsdp-00.txt
4 August 7, 1998
5 Expires January 1, 1999
7 Integrating SDP Functionality Into SMIL
9 Philipp Hoschka, W3C
10 _________________________________________________________________
12 1. Status of this Memo
14 This document is an Internet Draft. Internet Drafts are working
15 documents of the Internet Engineering Task Force (IETF), its Areas,
16 and its Working Groups. Note that other groups may also distribute
17 working documents as Internet Drafts. Internet Drafts are valid for a
18 maximum of six months and may be updated, replaced, or obsoleted by
19 other documents at any time. It is inappropriate to use Internet
20 Drafts as reference material or to cite them other than as a "working
21 draft" or "work in progress." Distribution of this memo is unlimited.
23 Table of Contents
25 1. Status of this Memo
26 2. Abstract
27 3. Example
28 3. Mapping Approach
29 4. Integrating SDP Fields into SMIL
30 4.1 Origin
31 4.1.1 origin Element
32 4.2 Session Name
33 Example
34 4.3 Session Info
35 4.3.1 info Element
36 4.3.2 Media level use
37 Example
38 4.4 URI
39 4.4.1 uri Element
40 4.5 Email Address
41 4.5.1 email Element
42 4.6 Phone
43 4.6.1 phone Element
44 4.7 Connection Data
45 4.8 Bandwidth
46 4.8.1 bandwidth Element
47 4.9 Times
48 4.9.1 times Element
49 4.10 Repeat Time
50 4.10.1 repeat-time Element
51 4.11 Time Adjustement
52 4.11.1 time-adjustement Element
53 4.12 Encryption Keys
54 4.12.1 key Element
55 4.13 Attributes
56 4.13.1 attribute Element
57 4.14 Media Announcements
58 Example
59 4.14.1 rtpmap Element
60 4.15 Suggested Attributes
61 Acknowledgements
62 Authors Address
64 2. Abstract
66 This document describes an approach for integrating the functionality
67 currently contained in [46]SDP (Session Announcement Protocol) into
68 [47]SMIL (Synchronized Multimedia Integration Language). The
69 motivation is to make it easier for SMIL authors to interface with the
70 existing RTP/MBone infrastructure. Currently, this requires
71 maintaining two different sets of files, each of which use a different
72 text format.
74 3. Example
76 The following shows how the sdp example contained in the SDP RFC can
77 be integrated into a SMIL file, using the mapping defined in this
78 document.
80 SDP announcement:
81 v=0
82 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
83 s=SDP Seminar
84 i=A Seminar on the session description protocol
85 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
86 e=mjh@isi.edu (Mark Handley)
87 c=IN IP4 224.2.17.12/127
88 t=2873397496 2873404696
89 a=recvonly
90 m=audio 49170 RTP/AVP 0
91 m=video 51372 RTP/AVP 31
92 m=application 32416 udp wb
93 a=orient:portrait
95 Inclusion in SMIL file:
96
99
100
104
105
106 A Seminar on the session description protocol
107
108
109 http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
110
111 ph@w3.org
112
113
114
115
126 3. Mapping Approach
128 Only the information contained in a SDP session announcement is mapped
129 onto SMIL. An SDP session announcement consists of several fields.
130 These fields can either be session level fields, or media level
131 fields. In general, information contained in SDP session level fields
132 are mapped into information contained within the "head" part of a SMIL
133 document. Information contained in SDP media level fields is mapped
134 onto information assiocated with individual media objects in a SMIL
135 document.
137 The mapping below allows integrating all information in a SDP
138 announcement into SMIL.
140 SDP information is included in a SMIL document in two different ways:
141 * mapping SDP information into existing attributes, when possible
142 * defining a set of new XML elements and attributes that can be
143 included into a SMIL document via the [48]XML namespace mechanism
145 4. Integrating SDP Fields into SMIL
147 4.1 Origin
149 This SDP field requires defining a new element.
151 4.1.1 origin Element
153 This represents the information of the "orgin" field in SDP. It is
154 mandatory for a SMIL document that is transmitted in a multicast
155 announcement.
157 Element Attributes
159 username
160 Syntax and semantics defined in SDP specification
162 session-id
163 Syntax and semantics defined in SDP specification
165 version
166 Syntax and semantics defined in SDP specification
168 network-type
169 Syntax and semantics defined in SDP specification
171 address-type
172 Syntax and semantics defined in SDP specification
174 address
175 Syntax and semantics defined in SDP specification
177 Element Content
179 "origin" is an empty element.
181 Example
183
185
186
190 ...
191
192 ...
193
195 4.2 Session Name
197 This SDP field can be mapped onto the "title" property of the SMIL
198 "meta" element.
200 Example
202
203
204
205 ...
206
207 ...
208
210 4.3 Session Info
212 This SDP field can be used in the session-level section and in a
213 media-level section.
215 For mapping session-level use into SMIL, this requires defining a new
216 element.
218 4.3.1 info Element
220 Element Attributes
222 xml:lang
223 Syntax and semantics defined in XML specifiation
225 Element Content
227 "info" element contains the text of the session description.
229 Example
231
233
234
235 A Seminar on the session description protocol
236
237 ...
238
239 ...
240
242 4.3.2 Media level use
244 For media-level use, the "info" field can be mapped onto the "title"
245 attribute.
247 Example
249
250
251
252
253
255 4.4 URI
257 This SDP field requires defining a new element.
259 4.4.1 uri Element
261 The element can only occur within the "head" part of a SMIL document.
263 Element Attributes
265 This element has no attributes.
267 Element Content
269 The element contains the URI value.
271 Example
273
275
276 http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
277 ...
278
279 ...
280
282 4.5 Email Address
284 This SDP field requires defining a new element.
286 4.5.1 email Element
288 The element can only occur within the "head" part of a SMIL document.
290 Element Attributes
292 This element has no attributes.
294 Element Content
296 The element contains the email address
298 Example
300
302
303 ph@w3.org
304 ...
305
306 ...
307
309 4.6 Phone
311 This session-level SDP field requires defining a new element.
313 4.6.1 phone Element
315 The element can only occur within the "head" part of a SMIL document.
317 Element Attributes
319 This element has no attributes.
321 Element Content
323 The element contains the phone number.
325 Example
327
329
330 +1 617 256 8113
331 ...
332
333 ...
334
336 4.7 Connection Data
338 The information of this SDP field is contained in the URI identifying
339 the resource.
341 The network type can either be deduced from the URI scheme, or be
342 completely transparent.
344 Determining the address type is either not necessary (because the URI
345 contains a hostname), or it can be derived from the URI scheme.
347 For addressing resources that are multicast, a new "mbone" URI scheme
348 is needed. It looks as follows:
350 "mbone:""/""/"
352 @@ check whether consistent with guidelines for doing URIs
354 Example
356 mbone:224.2.1.1./127/3
358 This SDP field can be used in the session-level section and in a
359 media-level section.
361 For mapping session-level use into SMIL, a "meta" element can be used
362 for defining a base URI.
364 Example
366
367
368
369 ...
370
371 ...
372
374 For mapping media-level use into SMIL, the connection data field can
375 be mapped onto the "src" attribute of a media-object element.
377 Example
379
380
381
382
383
385 4.8 Bandwidth
387 This SDP field requires defining a new element.
389 4.8.1 bandwidth Element
391 Element Attributes
393 modifier
394 Syntax and semantics defined in SDP specifiation
396 bandwidth
397 Syntax and semantics defined in SDP specifiation
399 Element Content
401 "bandwidth" is an empty element.
403 The "bandwidth" SDP field can be used in the session-level section
404 and in a media-level section.
406 Use this field in the session-level section is mapped onto using the
407 "bandwidth" element in the "head" part of a SMIL document.
409 Example
411
413
414
415 ...
416
417 ...
418
420 Use of this field in the media-level section is mapped onto using the
421 "bandwitdh" element as content of a SMIL media object.
423 Example
425
427
428
431
432
434 4.9 Times
436 This session-level SDP field requires defining a new element.
438 4.9.1 times Element
440 The element can only occur within the "head" part of a SMIL document.
442 Element Attributes
444 start-time
445 Syntax and semantics defined in SDP specifiation
447 stop-time
448 Syntax and semantics defined in SDP specifiation
450 Element Content
452 The "times" element can contain the following element:
454 repeat-time
455 Defined below
457 zone-adjustement
458 Defined below
460 Example
462
464
465
466
467 ..
468
470 4.10 Repeat Time
472 This session-level SDP field requires defining a new element.
474 4.10.1 repeat-time Element
476 The element can only occur within the "head" part of a SMIL document
477 as content of a "time" element. The "time" element can contain not
478 more than one "repeat-time" element.
480 Element Attributes
482 interval
483 Syntax and semantics defined in SDP specifiation
485 active-duration
486 Syntax and semantics defined in SDP specifiation
488 offsets
489 A comma seperated list of values whose semantics is defined in
490 the SDP specification
492 Element Content
494 "repeat-times" is an empty element.
496 Example
498
500
501
502
504
505
506 ...
507
509 4.11 Time Adjustement
511 This session-level SDP field requires defining a new element.
513 4.11.1 time-adjustement Element
515 The element can only occur within the "head" part of a SMIL document
516 as content of a "time" element. The "time" element can contain
517 multiple "time-adjustement" elements, one for each adjustement (note
518 that this leads to a different structure than used by the "z" field in
519 sdp).
521 Element Attributes
523 adjustement-time
524 Syntax and semantics defined in SDP specifiation
526 offset
527 Syntax and semantics defined in SDP specifiation
529 Element Content
531 "time-adjustement" is an empty element.
533 Example
535
537
538
539
541
542
543
544
545 ...
546
548 4.12 Encryption Keys
550 This SDP field can be used both at the session-level and at the media
551 level. It requires defining a new element.
553 4.12.1 key Element
555 Element Attributes
557 method
558 Syntax and semantics defined in SDP specifiation
560 encryption-key
561 Syntax and semantics defined in SDP specifiation
563 Element Content
565 "key" is an empty element.
567 To mimic SDP use of encryption keys at the session-level, the "keys"
568 element is included in the "head" part of the SMIL document.
570 Example
572
574
575
576
577 ...
578
580 To mimic SDP-use of encryption keys at the media-level, the "keys"
581 element is included in the content of a SMIL media object element.
583 Example
585
587
588
591
592
594 4.13 Attributes
596 Unless specified otherwise, SDP attributes are mapped onto a generic
597 "attribute" element.
599 4.13.1 attribute Element
601 Element Attributes
603 attribute-name
604 Syntax and semantics defined in SDP specifiation
606 value
607 Syntax and semantics defined in SDP specifiation
609 Element Content
611 "attribute" is an empty element
613 If the attribute is used on the session-level, it is contained in the
614 "head" section of the SMIL document.
616 Example
618
620
621
623
624 ...
625
627 Otherwise, it is included in the content of a SMIL media-object
628 element.
630 Example
632
634
635
638
639
641 4.14 Media Announcements
643 The "m" SDP field is mapped onto attributes within SMIL media objects.
645 The following attributes can be added to all SMIL media objects:
647 port
648 Syntax and semantics defined in SDP specifiation
650 transport
651 Syntax and semantics defined in SDP specifiation
653 fmt-list
654 Comma-seperated list of values whose syntax and semantics is
655 defined in SDP specifiation
657 Example
659
661
662
665
666
668 If the media object uses the RTP format, and uses a dynamic payload
669 type, SDP requires the use of the "rtpmap" attribute field. This is
670 mapped onto the "rtpmap" element, which is contained in the content of
671 the media object element.
673 4.14.1 rtpmap Element
675 Element Attributes
677 payload
678 Syntax and semantics defined in SDP specifiation
680 encoding
681 Syntax and semantics defined in SDP specifiation
683 Element Content
685 "rtpmap" is an empty element
687 Example
689
691
692
698
699
701 4.15 Suggested Attributes
703 The following "suggested attributes" of SDP are not mapped onto an
704 "attribute" element:
705 * charset: The charset of the SMIL document can be set using the
706 mechanisms defined by the XML definition.
707 * sdplang: The language of session-description information is set by
708 the "xml:lang" attribute in the individual "info" elements.
709 @@@ check XML spec: is there a way to set a global default
710 language that is valid for the whole document ?
711 * lang: The functionality of this is replaced by the
712 "system-language" attribute in SMIL.
714 All other "suggested attributes" are mapped onto an "attribute"
715 element.
717 Acknowledgements
719 Integrating SDP functionality with SMIL has been originally suggested
720 by several other people to me in private.
722 Authors Address
724 * Philipp Hoschka
725 W3C/MIT Laboratory for Computer Science
726 545 Technology Square
727 Cambridge, MA 02139, USA
728 Fax: +1 (617) 258-8682
729 Email: ph@w3.org
730 _________________________________________________________________
732 References
734 46. http://info.internet.isi.edu/in-notes/rfc/files/rfc2327.txt
735 47. http://www.w3.org/TR/REC-smil
736 48. http://www.w3.org/TR/WD-xml-names