idnits 2.17.1 draft-goland-http-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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. 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 (December 1999) is 8896 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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Yaron Y. Goland 2 INTERNET DRAFT Microsoft Corporation 3 June 21, 1999 4 Expires December 1999 6 Multicast and Unicast UDP HTTP Messages 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 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. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document provides rules for encapsulating HTTP messages in 33 Multicast and Unicast UDP packets to be sent within a single 34 administrative scope. No provisions are made for associating 35 requests with responses or for guaranteeing delivery beyond 36 rebroadcasting. 38 1. Introduction 40 This document provides rules for encapsulating HTTP messages in 41 Multicast and Unicast UDP packets to be sent within a single 42 administrative scope. No provisions are made for associating 43 requests with responses or for guaranteeing delivery beyond 44 rebroadcasting. 46 This technology is motivated by applications such as SSDP where it 47 is expected that messages which are primarily transmitted over TCP 48 HTTP need to be transmitted over Multicast or Unicast UDP in extreme 49 circumstances. 51 2. Terminology 53 Since this document describes a set of extensions to the HTTP/1.1 54 protocol, the augmented BNF used herein to describe protocol 55 elements is exactly the same as described in section 2.1 of 56 [RFC2616]. Since this augmented BNF uses the basic production rules 57 provided in section 2.2 of [RFC2616], these rules apply to this 58 document as well. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 3. HTTPU URL 66 The HTTPU URL specifies that the HTTP request is to be sent over 67 unicast UDP according to the rules laid out in this document. 69 httpu_URL = "httpu:" "//" host [ ":" port ] [ abs_path ] 71 The BNF productions host, port and abs_path are defined in 72 [RFC2616]. 74 The syntax of the HTTPU URL is to be processed identically to the 75 HTTP URL with the exception of the transport. 77 One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are 78 identical in all ways save the protocol that they necessarily point 79 to the same resource. 81 4. HTTPMU URL 83 The HTTPMU URL specifies that the HTTP request that HTTP request is 84 to be sent over multicast UDP according to the rules laid out in 85 this document. 87 httpmu_URL = "httpmu:" "//" host [ ":" port ] [ abs_path ] 89 The syntax of the HTTPMU URL is to be processed identically to the 90 HTTP URL other than the absence of abs_path will result in the 91 request-URI of the HTTPMU request being set to "*" rather than "/". 93 5. Unicast UDP HTTP Messages 95 HTTP messages sent over unicast UDP function identically to HTTP 96 messages sent over TCP as defined in [RFC2616] except as specified 97 below. 99 All messages sent over unicast UDP MUST fit entirely in a single UDP 100 packet. If a message can not be fit into a single UDP packet then it 101 MUST NOT be sent using unicast UDP. Incomplete messages SHOULD be 102 ignored. 104 The request-URI of a HTTP message sent over unicast UDP MUST always 105 be fully qualified. 107 A single unicast UDP packet MUST only contain a single HTTP message. 109 Replies to unicast UDP HTTP requests are sent to the IP address and 110 port that sent the request. 112 6. Multicast UDP HTTP Requests 114 HTTP messages sent over multicast UDP MUST obey all the requirements 115 for HTTP requests sent over unicast UDP in addition to the 116 requirements provided below. 118 Resources that support receiving multicast UDP HTTP requests MUST 119 honor the mm and mx headers if included in the request. 121 When used with a multicast UDP HTTP request the "*" request-URI 122 means "to everyone who is listening to this IP address and port." 124 By default httpmu requests are not responded to. This default MAY be 125 overridden on a method-by-method basis. 127 [Ed. Note: This one bugs me, I suspect we will end up putting in a 128 flag so that any intermediaries such as proxies will know what's up 129 without having to know anything about the particular method.] 131 7. Retrying Requests 133 UDP is an inherently unreliable transport and subject to routers 134 dropping packets without notice. Applications requiring delivery 135 guarantees SHOULD NOT use httpu or httpmu. 137 In order to increase the probability that a httpu or httpmu message 138 is delivered the message may be repeated several times. 140 In order to prevent the network from being flooded a message SHOULD 141 NOT be repeated more than MAX_RETRIES time. A random period of time 142 between MIN_RETRY_INTERVAL and MAX_RETRY_INTERVAL SHOULD be selected 143 between each retry to determine how long to wait before issuing the 144 retry. 146 8. Caching UDP HTTP Requests 148 Caching of httpu and httpmu request/responses is certainly possible 149 following the normal HTTP caching rules. However there is no 150 mechanism provided in this specification to associated requests with 151 responses. Therefore if a client sends multiple requests to a single 152 resource there is no generic mechanism to tell the responses apart. 153 This restriction has not proven to be a problem for the sorts of 154 applications that intend to use httpu and httpmu. Therefore if there 155 is a strong desire to provide for generic association between 156 requests and replies through the use of request Ids are similar 157 mechanism this feature should be added in an extension 158 specification, as it is not necessary for many applications and thus 159 would prove to be a needless burden. 161 9. Proxying UDP HTTP Requests 163 Just as it is possible to cache a httpu or httpmu request/response 164 pair so it is possible to proxy such requests. The same warnings 165 provided in section .8 apply. 167 10. HTTP Headers 169 10.1. AL Header 171 AL = "AL" ":" 1*("<" AbsoluteURI ">") ; AbsoluteURI is defined in 172 section 3.2.1 of [RFC2616] 174 The AL header is an extension of the Location header. The contents 175 of an AL header are ordered. If both a Location header and an AL 176 header are included in the same request then the URI in the location 177 header is to be treated as if it were the first entry in the AL 178 header. The AL header MAY be used by itself but implementers should 179 be aware that existing systems will ignore the header. 181 10.2. mm Request Header 183 mm = "mm" ":" Integer 184 Integer = First_digit *More_digits 185 First_digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 186 More_digits = "0" | First_digit 188 Indicates the minimum number of seconds that a multicast UDP HTTP 189 resource MUST wait before it sends a response stimulated by a 190 multicast request. 192 10.3. mx Request Header 194 mx = "mx" ":" Integer 196 Indicates the maximum number of seconds that a multicast UDP HTTP 197 resource MUST wait before it sends a response stimulated by a 198 multicast request. 200 11. Security Considerations 202 [Ed. Note: Besides putting in a note that all the normal HTTP 203 security considerations apply we need to put in a discussion of the 204 problems associated with requests getting lost as well as over sized 205 request problem. We also need to talk about the fact that requests 206 can get randomly lost. We also need to discuss how one uses 207 authentication over UDP. Specifically, that one needs to assume the 208 challenge and send the response as part of the request.] 210 12. Constants 212 MAX_RETRIES - 3 214 MIN_RETRY_INTERVAL - 0 second 216 MAX_RETRY_INTERVAL - 10 seconds 218 13. References 220 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 221 Requirement Levels. RFC 2119, March 1997. 223 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. 224 Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol - 225 HTTP/1.1. RFC 2616, November 1998. 227 14. Author's Address 229 Yaron Y. Goland 230 Microsoft Corporation 231 One Microsoft Way 232 Redmond, WA 98052 234 Email: yarong@microsoft.com 236 This document will expire in September 1999.