idnits 2.17.1 draft-ivov-dispatch-sdpfrag-02.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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 14, 2013) is 3845 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) == Missing Reference: 'TODO' is mentioned on line 107, but not defined == Unused Reference: 'RFC3264' is defined on line 122, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 136, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Standards Track A. Roach 5 Expires: April 17, 2014 Mozilla 6 October 14, 2013 8 A Session Initiation Protocol (SIP) usage for Trickle ICE 9 draft-ivov-dispatch-sdpfrag-02 11 Abstract 13 This document registers the application/sdpfrag Multipurpose Internet 14 Mail Extensions (MIME) media type. This type is similar to 15 application/sdp, but allows certain subsets of well formed session 16 descriptions, as per the Session Description Protocol (SDP), to be 17 represented instead of requiring a complete SDP session description. 18 The "a=candidate" lines that are incrementally exchanged between 19 Trickle ICE agents are one example usage of the application/sdpfrag. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 17, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Definition: application/sdpfrag . . . . . . . . . . . . . . 2 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 62 6.2. Informative References . . . . . . . . . . . . . . . . . 3 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 65 1. Introduction 67 The application/sdp MIME media type defined in [RFC4566] carries an 68 entire well formed SDP session description. Yet, creating such a 69 description may sometimes require a relatively long time as, for 70 example, would be the case when the Interactive Connectivity 71 Establishment (ICE) [RFC5245] protocol is in use and candidates need 72 to be acquire in different, often time consuming methods. Some 73 applications may therefore choose to use mechanisms like Trickle ICE 74 [I-D.ivov-mmusic-trickle-ice] that would allow them to send initial 75 session descriptions with only readily available information and then 76 exchange candidates only when they become available. 78 This document does NOT provide a mechanism to segment an SDP session 79 description into multiple pieces for separate transport and later 80 reassemble. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Definition: application/sdpfrag 90 A valid application/sdpfrag part is one that could be obtained by 91 starting with some valid SDP session description and deleting any 92 number of lines. 94 [TODO maybe mention that we can only do frags with the declarative 95 parts of an SDP offer/answer and not with the ones used in 96 negotiations.] 98 [TODO maybe explain how attributes can be linked to an m line or at 99 least say that this will be defined by usages.] 101 4. Security Considerations 103 [TODO] 105 5. Acknowledgements 107 [TODO] 109 6. References 111 6.1. Normative References 113 [I-D.ivov-mmusic-trickle-ice] 114 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 115 Incremental Provisioning of Candidates for the Interactive 116 Connectivity Establishment (ICE) Protocol", draft-ivov- 117 mmusic-trickle-ice-01 (work in progress), March 2013. 119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 120 Requirement Levels", BCP 14, RFC 2119, March 1997. 122 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 123 with Session Description Protocol (SDP)", RFC 3264, June 124 2002. 126 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 127 Description Protocol", RFC 4566, July 2006. 129 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 130 (ICE): A Protocol for Network Address Translator (NAT) 131 Traversal for Offer/Answer Protocols", RFC 5245, April 132 2010. 134 6.2. Informative References 136 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 137 E. Lear, "Address Allocation for Private Internets", BCP 138 5, RFC 1918, February 1996. 140 Authors' Addresses 141 Emil Ivov 142 Jitsi 143 Strasbourg 67000 144 France 146 Phone: +33 6 72 81 15 55 147 Email: emcho@jitsi.org 149 Adam Roach 150 Mozilla 151 Dallas, TX 152 US 154 Email: adam@nostrum.com