idnits 2.17.1 draft-goland-http-udp-01.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: ---------------------------------------------------------------------------- ** 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? == There is 1 instance of lines with non-ascii characters in the document. == 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 (April 2000) is 8748 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: 5 errors (**), 0 flaws (~~), 2 warnings (==), 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 November 9, 1999 4 Expires April 2000 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 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 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 Please send comments to the SSDP mailing list. Subscription 31 information for the SSDP mailing list is available at 32 http://www.upnp.org/resources/ssdpmail.htm. 34 Abstract 36 This document provides rules for encapsulating HTTP messages in 37 Multicast and Unicast UDP packets to be sent within a single 38 administrative scope. No provisions are made for guaranteeing 39 delivery beyond re-broadcasting. 41 1. Introduction 43 This document provides rules for encapsulating HTTP messages in 44 multicast and unicast UDP messages. No provisions are made for 45 guaranteeing delivery beyond re-broadcasting. 47 This technology is motivated by applications such as SSDP where it 48 is expected that messages which are primarily transmitted over TCP 49 HTTP need to be transmitted over Multicast or Unicast UDP in extreme 50 circumstances. 52 This document will not specify a mechanism suitable for replacing 53 HTTP over TCP. Rather this document will define a limited mechanism 54 only suitable for extreme circumstances where the use of TCP is 55 impossible. Thus this mechanism will not have the robustness of 56 functionality and congestion control provided by TCP. It is expected 57 that in practice the mechanisms specified here in will only be used 58 as a means to get to TCP based HTTP communications. 60 2. Changes 61 2.1. Since 00 62 Divided each section of the spec into three parts, problem 63 definition, proposed solution and design rationale. When the spec is 64 ready for standardization the problem definition and design 65 rationale sections will be removed. Design rationale is presented in 66 question/answer form because I have found that to be very effective 67 in addressing design issues. 69 Clarified that a HTTPU/HTTPMU URI without an abs_path translates to 70 "*" in the request-URI. 72 Added the "S" header to allow request and responses to be 73 associated. Note that while clients aren't require to send out "S" 74 headers servers are required to return them. 76 Got rid of MM. The lower bound is always 0. 78 The introduction of the "S" makes proxying and caching possible so 79 the sections on those topics have been expanded, but they should be 80 considered experimental at best. 82 3. Terminology 84 Since this document describes a set of extensions to the HTTP/1.1 85 protocol, the augmented BNF used herein to describe protocol 86 elements is exactly the same as described in section 2.1 of 87 [RFC2616]. Since this augmented BNF uses the basic production rules 88 provided in section 2.2 of [RFC2616], these rules apply to this 89 document as well. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 4. HTTPU URL 97 4.1. Problem Definition 99 A mechanism is needed to allow for communications that are to be 100 sent over Unicast UDP HTTP to be identified in the URI namespace. 102 4.2. Proposed Solution 103 The HTTPU URL specifies that the HTTP request is to be sent over 104 unicast UDP according to the rules laid out in this document. 106 HTTPU_URL = "HTTPU:" "//" host [ ":" port ] [ abs_path [ "?" query]] 108 The BNF productions host, port and abs_path are defined in 109 [RFC2616]. 111 The syntax of the HTTPU URL is to be processed identically to the 112 HTTP URL with the exception of the transport. 114 One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are 115 identical in all ways save the protocol that they necessarily point 116 to the same resource. 118 4.3. Design Rationale 120 4.3.1. Why would we ever need a HTTPU/HTTPMU URL? 122 Imagine one wants to tell a system to send responses over HTTPU. How 123 would one express this? If one uses a HTTP URL there is no way for 124 the system to understand that you really meant HTTPU. 126 5. HTTPMU URL 128 5.1. Problem Definition 130 A mechanism is needed to allow for communications that are to be 131 sent over Multicast UDP HTTP to be identified in the URI namespace. 133 5.2. Proposed Solution 135 The HTTPMU URL specifies that the HTTP request that HTTP request is 136 to be sent over multicast UDP according to the rules laid out in 137 this document. 139 HTTPMU_URL = "HTTPMU:" "//" host [ ":" port ] [ abs_path [ "?" 140 query]] 142 The BNF productions host, port and abs_path are defined in 143 [RFC2616]. 145 The syntax of the HTTPMU URL is to be processed identically to the 146 HTTP URL with the exception of the transport. 148 One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are 149 identical in all ways save the protocol that they necessarily point 150 to the same resource. 152 If a HTTPMU URL does not have an abs_path element then when the HTTP 153 UDP multicast request is made the request-URI MUST be "*". 155 For example, HTTPU://www.foo.com would translate into a request-URI 156 of "*". Note, however, that HTTPU://www.foo.com/ would translate 157 into a request-URI of "/". 159 5.3. Design Rationale 161 5.3.1. In the HTTPMU URL a request such as http://www.foo.com is 162 translated to a "*" in the request-URI rather than a "/", why isn't the 163 same the case for HTTPU? 165 A HTTPU request is a point-to-point request. There is one sender and 166 one receiver. Thus the semantics of the URL are identical to HTTP 167 with the exception of the transport. 169 In HTTPMU a request, generally, is going to many receivers. The way 170 to indicate this on a HTTPMU request is by using the URI "*". Since 171 using "*" is probably the single most common way to send a HTTPMU 172 request there needed to be a way to indicate that the request-URI 173 should be "*". There is no way to do that today with a HTTP URL. 174 Therefore a mechanism had to be added. 176 As a side note, one could send a point-to-point request of HTTPMU. 177 One need only put a particular request-URI in the request. Only the 178 resource matching that request-URI will respond. 180 6. Unicast UDP HTTP Messages 182 6.1. Problem Definition 184 A mechanism is needed to send HTTP messages over the unicast UDP 185 transport. 187 6.2. Proposed Solution 189 HTTP messages sent over unicast UDP function identically to HTTP 190 messages sent over TCP as defined in [RFC2616] except as specified 191 below. 193 For brevity's sake HTTP messages sent over unicast UDP will be 194 referred to as HTTPU messages. 196 HTTPU messages MUST fit entirely in a single UDP message. If a HTTPU 197 message can not be fit into a single UDP message then it MUST NOT be 198 sent using unicast UDP. Incomplete HTTPU messages SHOULD be ignored. 200 The request-URI of a HTTPU message MUST always be fully qualified. 202 A single unicast UDP message MUST only contain a single HTTPU 203 message. 205 A HTTPU request without a "S" header MUST NOT be responded to. When 206 responding to a HTTPU request with a "S" header the rules for the 207 proper handling of "S" headers, as specified in section 11.3 MUST be 208 followed. 210 6.3. Design Rationale 212 See section 11.3.3 for the design rationale of the "S" header. 214 6.3.1. Why can't a single HTTP message be sent over multiple UDP 215 messages? 217 The ability to send unlimited size messages across the Internet is 218 one of the key features of TCP. The goal of this paper is not to re- 219 invent TCP but rather to provide a very simple emergency back up 220 HTTP system that can leverage UDP where TCP can not be used. As such 221 features to allow a single HTTP message to span multiple UDP 222 messages is not provided. 224 6.3.2. Why are request-URIs sent over HTTPU required to be fully 225 qualified? 227 A relative URI in a HTTP message is assumed to be relative to a HTTP 228 URL. However this would clearly be inappropriate for a HTTPU or 229 HTTPMU message. The easiest solution would be to simply state that a 230 relative URI is relative to the type of message it was sent in. But 231 one of the unstated (but now stated) goals of this draft is to allow 232 current HTTP message processors to be able to happily munch on 233 HTTPU/HTTPMU messages and this would cause a change to those 234 processors. Besides, relative URIs were always wacky, a left over 235 from the early days of HTTP. 236 The cost of this simplification is that you repeat the host 237 information, once in the URI and once in the host header. 238 Eventually the host header will go away and we will all use fully 239 qualified URIs. But again, taking out the host header would make a 240 lot of existing HTTP message munchers very unhappy. 242 6.3.3. Why is the requirement for ignoring incomplete HTTPU messages 243 a SHOULD instead of a MUST? 245 Some systems use a lot of redundant data or have good mechanisms for 246 handling partial data. As such they could actually do something 247 intelligent with a partial message. A SHOULD allows them to do this 248 while still making it clear that in the majority case partial 249 HTTPU/HTTPMU messages are going to get thrown out. 251 6.3.4. Why aren't multiple HTTP messages allowed into a single UDP 252 message if they will fit? 254 It was easier to ban it and it didn't seem to buy us much. It was 255 especially worrying because it would start to convince people that 256 they could actually order their UDP requests in a pipelinesque 257 manner. It was easier to just keep things simple and ban it. 259 6.3.5. Why aren't we allowed to leave off content-lengths if only a 260 single HTTPU message is allowed in a UDP message? 262 In general we try to only change from RFC 2616 when we are forced 263 to. Although including a content-length is annoying it makes it easy 264 to use HTTP/1.1 message parsing/generating systems with this spec. 266 6.3.6. Why might a HTTPU message choose to not have a "S" header 267 thus making it impossible to respond to it? 269 Leaving off the "S" header would be useful for throw away events. In 270 systems with a high event rate it is usually easier to just throw 271 away an event rather than re-sending it. As such there is no real 272 benefit to confirming that the event was received since it won't be 273 resent if it wasn't received. 275 6.3.7. Why isn't the mx header used on HTTPU messages? 277 As HTTPU messages are point-to-point there will be exactly one 278 response. Mx is only useful in cases, such as HTTPMU requests, where 279 there can be many potential responses from numerous different 280 clients. Mx helps to prevent the client from getting creamed with 281 responses. 283 6.3.8. Can I send 1xx responses over HTTPU? 285 Yes. Error handling is identical to RFC 2616. 287 7. Multicast UDP HTTP Requests 289 7.1. Problem Definition 291 A mechanism is needed to send HTTP messages over the multicast UDP 292 transport. 294 7.2. Proposed Solution 296 HTTP messages sent over multicast UDP MUST obey all the requirements 297 for HTTPU messages in addition to the requirements provided below. 299 For brevity's sake HTTP messages sent over multicast UDP will be 300 referred to as HTTPMU messages. 302 Resources that support receiving multicast UDP HTTP requests MUST 303 honor the mx header if included in the request. 305 Resources are required to generate a random number between 0 and mx 306 that represents the number of seconds the resource must wait before 307 sending a response. This prevents all responses from being sent at 308 once. HTTP clients SHOULD keep listening for responses for a 309 reasonable delta of time after mx. That delta will be based on the 310 type of network the request is being sent over. This means that if a 311 server cannot respond to a request before mx then there is little 312 point in sending the response as the client will most likely not be 313 listening for it. 315 When used with a multicast UDP HTTP request the "*" request-URI 316 means "to everyone who is listening to this IP address and port." 318 A HTTPMU request without a mx header MUST NOT be responded to. 320 7.3. Design Rationale 322 7.3.1. Why is there a "delta" after the mx time when the client 323 should still be listening? 325 So let's say the mx value is 5 seconds. The HTTP resource generates 326 a number between 0 and 5 and gets 5. After 5 seconds of waiting the 327 HTTP resource will send its response. 329 Now for some math: 330 0.5 seconds - Time it took the client's request to reach the HTTP 331 resource. 332 5 seconds - Time the HTTP resource waited after receiving the 333 message to respond, based on the mx value. 334 0.5 seconds - Time for the response to get back to the client. 335 Total time elapsed - 6 seconds 337 If the client only waits 5 seconds, the mx value, then they would 338 have stopped listening for this response by the time it arrived. 339 Hence the need for the delta. 341 7.3.2. What should the "delta" after mx expires be? 343 Unfortunately this is an impossible question to answer. How fast is 344 your network? How far is the message going? Is there any congestion? 345 In general delta values will be set based on a combination of 346 heuristics and application necessity. That is, if you are displaying 347 information to a user any data that comes in after 20 or 30 seconds 348 is probably too late. 350 7.3.3. When would a HTTPMU request not be responded to? 352 When a HTTP resource is making a general announcement, such as "I am 353 here", it generally isn't useful to have everyone respond confirming 354 they received the message. This is especially the case given that 355 the HTTP resource probably doesn't know who should have received the 356 announcement so the absence of a HTTP client in the responses 357 wouldn't be meaningful. 359 7.3.4. Why do we require the mx header on HTTPMU requests that are 360 to be responded to? 361 This is to prevent overloading the HTTP resource. If all the HTTP 362 clients responded simultaneously the resource would probably loose 363 most of the responses as its UDP buffer overflowed. 365 8. Retrying Requests 367 8.1. Problem Definition 369 UDP is an unreliable transport with no failure indicators, as such 370 some mechanism is needed to reasonably increase the chance that a 371 HTTPU/HTTPMU message will be delivered. 373 8.2. Proposed Solution 375 UDP is an inherently unreliable transport and subject to routers 376 dropping packets without notice. Applications requiring delivery 377 guarantees SHOULD NOT use HTTPU or HTTPMU. 379 In order to increase the probability that a HTTPU or HTTPMU message 380 is delivered the message MAY be repeated several times. 382 In order to prevent the network from being flooded a message SHOULD 383 NOT be repeated more than MAX_RETRIES time. A random period of time 384 between 0 and MAX_RETRY_INTERVAL SHOULD be selected between each 385 retry to determine how long to wait before issuing the retry. 387 8.3. Design Rationale 389 8.3.1. Why is the requirement "applications requiring delivery 390 guarantees should not use HTTPU or HTTPMU" only a SHOULD and not a 391 MUST? 393 Because there might come a day when it makes sense to use HTTPU or 394 HTTPMU for guaranteed delivery and there is no reason to completely 395 ban the possibility. 397 8.3.2. Why is the requirement that a request not be repeated more 398 than MAX_RETRIES times a SHOULD and not a MUST? 400 Local knowledge may make the limit unnecessary. For example, if one 401 knew that the message was being delivered using a super reliable 402 network then repeats are not necessary. Similarly if one knew that 403 the network the requests were going through were particularly 404 unreliable and assuming one had properly accounted for the effects 405 of additional messages on that congestion, one might have a good 406 reason to send more than MAX_RETRIES. 408 9. Caching UDP HTTP Requests 410 9.1. Problem Definition 411 Caching is a feature that has demonstrated its usefulness in HTTP, 412 provisions need to be made so as to ensure that HTTPU/HTTPMU 413 messages can be cached using a consistent algorithm. 415 9.2. Proposed Solution 417 [Ed. Note: Never having tried to actually build a HTTPU/HTTPMU 418 generic cache we suspect there are some very serious gotchas here 419 that we just haven't found yet. This section should definitely be 420 treated as "under development."] 422 Caching rules for HTTPU/HTTPMU responses are no different than 423 normal HTTP responses. HTTPU/HTTPMU responses are matched to their 424 requests through the "S" header value. 426 9.3. Design Rationale 428 9.3.1. Wouldn't it be useful to be able to cache HTTPU/HTTPMU 429 requests if they don't have responses? 431 Yes, it probably would. Especially if we are talking about a client 432 side cache. It is probably worth investigating the use of cache 433 control headers on requests for this very purpose. 435 10. Proxying UDP HTTP Requests 437 10.1. Problem Definition 439 For security or caching reasons it is sometimes necessary to place a 440 proxy in a message path. Provisions need to be made so as to ensure 441 that HTTPU/HTTPMU messages can be proxied. 443 10.2. Proposed Solution 445 [Ed. Note: This section should be considered experimental. No one 446 has really had to design much less implement a HTTPU/HTTPMU proxy 447 yet.] 449 All transport independent rules for proxying, such as length of time 450 to cache a response, hop-by-hop header rules, etc. are the same for 451 HTTPU/HTTPMU as they are for HTTP messages. 453 [Ed. Note: I'm not sure how far to go into the "transport 454 independent rules". The RFC 2616 doesn't really call them out very 455 well but I also don't want to have to re-write RFC 2616 spec inside 456 this spec.] 458 The transport dependent rules, however, are different. For example, 459 using TCP any pipelined messages are guaranteed to be delivered in 460 order. There are no ordering guarantees of any form for HTTPU/HTTPMU 461 proxies. 463 In general a proxy is required to forward a HTTPU/HTTPMU message 464 exactly once. It SHOULD NOT repeat the message. Rather the client is 465 expected to repeat the message and, as the proxy receives the 466 repeats, they will be forwarded. 468 The proxy is only responsible for forwarding responses to requests 469 that include a "S" header. As with HTTPU/HTTPMU requests, responses 470 SHOULD NOT be repeated. 472 Note that it is acceptable, if not encouraged, for proxies to 473 analyze network conditions and determine the likelihood, on both 474 incoming and outgoing connections, of UDP messages being dropped. If 475 the likelihood is too high then it would be expected for the proxy, 476 taking into consideration the possibility of making congestion even 477 worse, to repeat requests and responses on its own. In a sense the 478 proxy could be thought of as a signal regenerator. This is why the 479 prohibition against repeating messages is a SHOULD NOT rather than a 480 MUST NOT. 482 HTTPMU messages are sent with the assumption that the message will 483 only be seen by the multicast address they were sent to. Thus when a 484 proxy forwards the request it is expected to only do so to the 485 appropriate multicast channel. Note, however, that proxies may act 486 as multicast bridges. 488 Also note that proxied HTTPMU messages with a HTTPMU URL without an 489 absolute path are to be treated as if they were sent to the 490 specified multicast address with the request-URI "*". 492 If a HTTPMU request is sent with a host that does not resolve to a 493 multicast address then the request MUST be rejected with a 400 Bad 494 Request error. 496 There is no requirement that a HTTPU proxy support HTTPMU or visa 497 versa. 499 10.3. Design Rationale 501 10.3.1. Why would anyone proxy HTTPMU requests? 503 Proxying HTTPMU requests can be a neat way to create virtual 504 multicast channels. Just hook a bunch of proxies together with 505 unicast connections and tell the proxies' users that they are all on 506 the same multicast scope. 508 11. HTTP Headers 510 11.1. AL Header 512 11.1.1. Problem Definition 513 There are many instances in which a system needs to provide location 514 information using multiple URIs. The Location header only allows a 515 single URI. Therefore a mechanism is needed to allow multiple 516 location URIs to be returned. 518 11.1.2. Proposed Solution 520 AL = "AL" ":" 1*("<" AbsoluteURI ">") ; AbsoluteURI is defined in 521 section 3.2.1 of [RFC2616] 523 The AL header is an extension of the Location header whose semantics 524 are the same as the Location header. That is, the AL header allows 525 one to return multiple locations where as the Location header allows 526 one to return only one. The contents of an AL header are ordered. If 527 both a Location header and an AL header are included in the same 528 request then the URI in the location header is to be treated as if 529 it were the first entry in the AL header. The AL header MAY be used 530 by itself but implementers should be aware that existing systems 531 will ignore the header. 533 11.1.3. Design Rationale 535 11.1.3.1. Why not just fix the BNF for the location header? 537 This is tempting but the goal of maintaining compatibility with RFC 538 2616's message format overrides the usefulness of this solution. 540 11.2. mx Request Header 542 11.2.1. Problem Definition 544 A mechanism is needed to ensure that responses to HTTPMU requests do 545 not come at a rate greater than the requestor can handle. 547 11.2.2. Proposed Solution 549 [Ed. Note: We need to put in a max for this, at least a number after 550 which the client isn�t required to respond. 32 bit integer seconds 551 sounds like overkill.] 553 mx = "mx" ":" Integer 554 Integer = First_digit *More_digits 555 First_digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 556 More_digits = "0" | First_digit 558 The value of the mx header indicates the maximum number of seconds 559 that a multicast UDP HTTP resource MUST wait before it sends a 560 response stimulated by a multicast request. 562 HTTP resources MAY treat any mx header value greater than MX_MAX as 563 being equal to MX_MAX. 565 11.2.3. Design Rationale 567 11.2.3.1. Why is mx in seconds? 569 In practice wait periods shorter than a second proved useless and 570 longer proved too coarse. Of course as faster networks get deployed 571 finer grain times would be useful but we need a compromise 572 measurement that will meet everyone's needs, seconds seem to do that 573 quite well. 575 11.2.3.2. Couldn't mx still overload the requestor if there are too 576 many responders? 578 Absolutely. If there are a 100,000 clients that want to respond even 579 pushing them over 30 seconds on a 10 Mbps link is still going to 580 blow both the client and the network away. However the only way to 581 prevent these sorts of situations is to know the current available 582 network bandwidth and the total number of likely responders ahead of 583 time. Both generally prove between difficult to impossible to figure 584 out. So we are left with heuristics and the mx header. 586 11.3. S General Header 588 11.3.1. Problem Definition 590 A mechanism is needed to associated HTTPU/HTTPMU requests with 591 responses as UDP does not have any connection semantics. 593 11.3.2. Proposed Solution 595 S = "S" ":" AbsoluteURI 597 The S header is a URI that is unique across the entire URI namespace 598 for all time. When a "S" header is sent on a HTTPU/HTTPMU request it 599 MUST be returned, with the same value, on the response. 601 If a client receives multiple responses with the same "S" header 602 then the client MAY assume that all the responses are from the same 603 source and in response to the same request. If the messages differ 604 from each other then the client MAY either throw all the responses 605 away or randomly choose one to honor. 607 [Ed. Note: Ipv4 guarantees that the minimum MTU is 512 bytes or so 608 long. The UUID URI takes 41 bytes if you don't add an extension 609 element plus 5 extra characters for header over giving 46 610 characters. Assuming that the UUID is the minimum practical 611 mechanism to guarantee globally unique messages this means that 612 about 9% of every message is eaten up just by the S header. This is 613 a lot. On the other hand most systems do much better than 512 bytes 614 and Ipv6 requires (if memory serves) 4k that reduces the overhead to 615 1%. Note that UDP messages are still 64k long but I know lots of 616 folks will want to optimize for a single UDP packet. 618 On the other hand, having a universally unique S header means that 619 the algorithm for handling headers is very easy - if you see the 620 same S value it is the same message. No worrying about rap arounds, 621 time windows, or anything else. This is very appealing.] 623 11.3.3. Design Rationale 625 11.3.3.1. Why do we need the "S" header? 627 Without a "S" header the only way to match requests with responses 628 is to ensure that there is enough information on the response to 629 know what request it was intended to answer. Even in that case it is 630 still possible to confuse which request a response goes to if it 631 does not have the equivalent of a "S" header. 633 11.3.3.2. Couldn't the "S" header be used as a cookie? 635 No, "S" headers are sent out by clients and returned by servers. 636 Cookies are sent out by servers and returned by clients. 638 11.3.3.3. Why aren't "S" headers mandatory on all requests with a 639 response? 641 Some systems don't need them. 643 11.3.3.4. Why aren't "S" headers guaranteed to be sequential so you 644 could do ordering? 646 Because HTTPU/HTTPMU is not interested in ordering. If one wants 647 ordering one should use TCP. 649 12. Security Considerations 651 [Ed. Note: Besides putting in a note that all the normal HTTP 652 security considerations apply we need to put in a discussion of the 653 problems associated with requests getting lost as well as over sized 654 request problem. We also need to talk about the fact that requests 655 can get randomly lost. We also need to discuss how one uses 656 authentication over UDP. Specifically, that one needs to assume the 657 challenge and send the response as part of the request.] 659 [Ed. Note: Talk about the danger of abusing S headers.] 661 13. Acknowledgements 663 Thanks to John Stracke for his excellent comments. 665 14. Constants 667 MAX_RETRIES - 3 669 MAX_RETRY_INTERVAL - 10 seconds 670 MAX_MX - 120 seconds 672 15. References 674 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 675 Requirement Levels. RFC 2119, March 1997. 677 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. 678 Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol - 679 HTTP/1.1. RFC 2616, November 1998. 681 16. Author's Address 683 Yaron Y. Goland 684 Microsoft Corporation 685 One Microsoft Way 686 Redmond, WA 98052 688 Email: yarong@microsoft.com 690 This document will expire in April 2000.