idnits 2.17.1 draft-fujikawa-sdp-url-01.txt: 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-26) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 4 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (7 August 1998) is 9394 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2327 (ref. '1') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-02) exists of draft-ohta-static-multicast-00 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT FUJIKAWA Kenji 3 draft-fujikawa-sdp-url-01.txt KURIYA Shinobu 4 Kyoto University 5 7 August 1998 7 SDP URL Scheme 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To view the entire list of current Internet-Drafts, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes a format for an Session Description Protocol 30 Uniform Resource Locator (SDP URL) which will allow Internet clients 31 to have direct access to multimedia sessions. 33 1. Introduction 35 SDP[1] is a format for describing information of multimedia sessions, 36 and generally is conveyed by SAP (Session Announcement Protocol)[4]. 37 However, SDP is just a format for session description and is intended 38 to use different transport protocols including SAP, E-mail and World 39 Wide Web (WWW). 41 An SDP file has to be saved in a WWW server for distributing SDP 42 messages when utilizing WWW. At first, Internet clients have access 43 to a WWW server to get an HTML file that has the URL of the SDP file. 45 Clients have to have another access to the server to get the SDP file 46 to start a multimedia session. 48 SDP URL scheme eliminates the second unnecessary access to a WWW 49 server. Since SDP URL is written directly on an HTML file, a session 50 can be started only by access to the HTML file with SDP URL. It is 51 not necessary to get another access to the server. 53 When a user clicks SDP URL in an HTML file, a WWW browser 54 automatically launch applications for participation in the session. 55 This is equal to selecting a session on an application such as sdr. 57 2. Description of the SDP Scheme 59 The SDP URL scheme is basically the same format as that of the 60 original SDP except for a few points. 62 A whitespace is replaced by '+', a return by '&', and the characters 63 reserved in RFC 1738[2] and a original '+' by ascii code described by 64 %xx. The term "RTP/AVP" which specifies a transport protocol is 65 replaced by the "RTP-AVP". The of 'v', 'o' and 's' which 66 cannot be omitted in the original SDP can be omitted. If 'v' is 67 omitted, then the SDP version of an SDP URL is regarded as 1. 69 URL is generally written in the format: 71 ://
:/ 73 SDP's connection information and session name correspond to
74 and respectively. 76 An SDP URL takes the form: 78 sdp://[
[:ttl=] [:noa=] ] / [] 79 [ #= *[&=] ] 81 The
is the connection address that will be either a unicast 82 IP address or a class-D IP multicast group address. The (time- 83 to-live) defines the scope with which multicast packets sent in a 84 session should be sent when the
is a multicast address. 85 The is ignored when the
is a unicast address. The 86 value of takes 1 when the is omitted. The (number- 87 of-addresses) is the number of multicast addresses contiguously 88 allocated above the base address
. 90 These can also be described as a connection information 'c' and the 91 as a session name 's'. The , the and 92 their order follow [1]. 94 3. Examples 96 The followings are some example SDP URLs using the format defined 97 above. A multimedia session is on a multicast address 224.192.2.3, 98 the session name "sdp test", TTL 16 and port 10000 . The media type 99 is audio, profile AVP and payload type PCM. 101 sdp://224.192.2.3:ttl=16/sdp+test 102 #m=audio+10000+RTP-AVP+0 104 This could also be written in 106 sdp:///#s=sdp+test&c=IN+IP4+224.192.2.3%2f16&m=audio+10000+RTP-AVP+0 108 The former description is preferable for look, suiting to the URL 109 convention. 111 Multicast addresses are registered in DNS in [3]. In this case, the 112 URL is also written as: 114 sdp://london-station.bbcc.com:ttl=16/sdp+test 115 #m=audio+10000+RTP-AVP+0 117 where ``london-station.bbcc.com'' is the domain name of the address 118 224.192.2.3. 120 Some services may use additional data. The time that a session is 121 active is specified. Both audio and video are used. All media 122 applications are requested to be receive-only and the maximum 123 framerate of video to be 10. 125 sdp://london-station.bbcc.com:ttl=16/sdp+test 126 #t=2873397496+2873404696&a=recvonly 127 &m=audio+10000+RTP-AVP+0 128 &m=video+9999+RTP-AVP+31&a=framerate:10 130 5. Considerations to Scope Rule 132 It is asserted that announcements of multicast sessions made via WWW 133 cause the mismatch between the scope where WWW is valid and the scope 134 restricted by the multicast addresses. [1] However, Ohta shows that 135 this is not a problem but the idea of scope has an essential problem. 136 [3] 138 6. QoS Specifications 140 The notation of RSVP parameters should be defined in [1] or in this 141 draft for the purpose of specifying Quality of Services (QoS). 143 7. Proposed Syntax 145 The proposed BNF syntax is encoded as specified in RFC 1738 [2]. 147 sdpurl = "sdp://" [ connection ] "/" [ sessionname ] 148 ["#" parameter *["&" parameter ] ] 150 connection = address [ ":ttl=" ttl ][ ":noa=" noa ] 151 address = addressname | addressnumber 152 addressname = *[ domainlabel "." ] toplabel 153 domainlabel = alphadigit | 154 alphadigit *[ alphadigit | "-" ] alphadigit 155 toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit 156 alphadigit = alpha | digit 157 addressnumber = digits "." digits "." digits "." digits 158 ttl = digits 159 noa = digits 160 digits = 1*digit 162 sessionname = 1*uchar 164 parameter = type "=" value 165 type = alpha 166 value = 1*uchar [ ":" attributevalue] 167 attributevalue = 1*uchar 169 alpha, digit and uchar are defined in RFC 1738. 171 References 173 [1] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 174 RFC 2327, Nov 1997. 176 [2] T. Berners-Lee, L. Masinter and M. Mccahill, "Uniform Resource 177 Locators (URL)", RFC 1738, Dec 1994. 179 [3] M. Ohta, J. Crowcroft, "Static Multicast", Internet Draft draft- 180 ohta-static-multicast-00.txt (work in progress), March 1998. 182 [4] M. Handley, "SAP: Session Announcement Protocol", Internet Draft 183 draft-ietf-mmusic-sap-00.txt (work in progress), Nov 1996. 185 Security Considerations 187 (to be written) 189 Appendix 191 A. Implementation 193 Implementation of an SDP URL interpreter for Emacs/WWW is available 194 at 195 "http://www.lab1.kuis.kyoto-u.ac.jp/members/magician/sdp-url-0.1.tar.gz". 197 Authors' Address 199 FUJIKAWA Kenji 200 Graduate School of Informatics, 201 Kyoto University 202 Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-01, Japan 203 Phone : +81 75-753-5387 204 Email : magician@kuis.kyoto-u.ac.jp 206 KURIYA Shinobu 207 Department of Information Science, 208 Faculty of Engineering, Kyoto University 209 Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-01, Japan 210 Phone : +81 75-753-5387 211 Email : kuriya@kuis.kyoto-u.ac.jp