Internet Engineering Task Force                        Yaron Y. Goland
INTERNET DRAFT                                   Microsoft Corporation
                                                         June 21, 1999
                                                 Expires December 1999



                Multicast and Unicast UDP HTTP Messages
                     <draft-goland-http-udp-00.txt>



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document provides rules for encapsulating HTTP messages in
   Multicast and Unicast UDP packets to be sent within a single
   administrative scope. No provisions are made for associating
   requests with responses or for guaranteeing delivery beyond
   rebroadcasting.

.   Introduction

   This document provides rules for encapsulating HTTP messages in
   Multicast and Unicast UDP packets to be sent within a single
   administrative scope. No provisions are made for associating
   requests with responses or for guaranteeing delivery beyond
   rebroadcasting.

   This technology is motivated by applications such as SSDP where it
   is expected that messages which are primarily transmitted over TCP
   HTTP need to be transmitted over Multicast or Unicast UDP in extreme
   circumstances.




Goland                                                        [Page 1]

INTERNET-DRAFT                 UDP HTTP                  June 21, 1999


.   Terminology

   Since this document describes a set of extensions to the HTTP/1.1
   protocol, the augmented BNF used herein to describe protocol
   elements is exactly the same as described in section 2.1 of
   [RFC2616].  Since this augmented BNF uses the basic production rules
   provided in section 2.2 of [RFC2616], these rules apply to this
   document as well.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

.   HTTPU URL

   The HTTPU URL specifies that the HTTP request is to be sent over
   unicast UDP according to the rules laid out in this document.

   httpu_URL = "httpu:" "//" host [ ":" port ] [ abs_path ]

   The BNF productions host, port and abs_path are defined in
   [RFC2616].

   The syntax of the HTTPU URL is to be processed identically to the
   HTTP URL with the exception of the transport.

   One MUST NOT assume that if a HTTP, HTTPU or HTTPMU URL are
   identical in all ways save the protocol that they necessarily point
   to the same resource.

.   HTTPMU URL

   The HTTPMU URL specifies that the HTTP request that HTTP request is
   to be sent over multicast UDP according to the rules laid out in
   this document.

   httpmu_URL = "httpmu:" "//" host [ ":" port ] [ abs_path ]

   The syntax of the HTTPMU URL is to be processed identically to the
   HTTP URL other than the absence of abs_path will result in the
   request-URI of the HTTPMU request being set to "*" rather than "/".

.   Unicast UDP HTTP Messages

   HTTP messages sent over unicast UDP function identically to HTTP
   messages sent over TCP as defined in [RFC2616] except as specified
   below.

   All messages sent over unicast UDP MUST fit entirely in a single UDP
   packet. If a message can not be fit into a single UDP packet then it
   MUST NOT be sent using unicast UDP. Incomplete messages SHOULD be
   ignored.


Goland                                                        [Page 2]

INTERNET-DRAFT                 UDP HTTP                  June 21, 1999



   The request-URI of a HTTP message sent over unicast UDP MUST always
   be fully qualified.

   A single unicast UDP packet MUST only contain a single HTTP message.

   Replies to unicast UDP HTTP requests are sent to the IP address and
   port that sent the request.

.   Multicast UDP HTTP Requests

   HTTP messages sent over multicast UDP MUST obey all the requirements
   for HTTP requests sent over unicast UDP in addition to the
   requirements provided below.

   Resources that support receiving multicast UDP HTTP requests MUST
   honor the mm and mx headers if included in the request.

   When used with a multicast UDP HTTP request the "*" request-URI
   means "to everyone who is listening to this IP address and port."

   By default httpmu requests are not responded to. This default MAY be
   overridden on a method-by-method basis.

   [Ed. Note: This one bugs me, I suspect we will end up putting in a
   flag so that any intermediaries such as proxies will know what's up
   without having to know anything about the particular method.]

.   Retrying Requests

   UDP is an inherently unreliable transport and subject to routers
   dropping packets without notice. Applications requiring delivery
   guarantees SHOULD NOT use httpu or httpmu.

   In order to increase the probability that a httpu or httpmu message
   is delivered the message may be repeated several times.

   In order to prevent the network from being flooded a message SHOULD
   NOT be repeated more than MAX_RETRIES time. A random period of time
   between MIN_RETRY_INTERVAL and MAX_RETRY_INTERVAL SHOULD be selected
   between each retry to determine how long to wait before issuing the
   retry.

.   Caching UDP HTTP Requests

   Caching of httpu and httpmu request/responses is certainly possible
   following the normal HTTP caching rules. However there is no
   mechanism provided in this specification to associated requests with
   responses. Therefore if a client sends multiple requests to a single
   resource there is no generic mechanism to tell the responses apart.
   This restriction has not proven to be a problem for the sorts of
   applications that intend to use httpu and httpmu. Therefore if there


Goland                                                        [Page 3]

INTERNET-DRAFT                 UDP HTTP                  June 21, 1999


   is a strong desire to provide for generic association between
   requests and replies through the use of request Ids are similar
   mechanism this feature should be added in an extension
   specification, as it is not necessary for many applications and thus
   would prove to be a needless burden.

.   Proxying UDP HTTP Requests

   Just as it is possible to cache a httpu or httpmu request/response
   pair so it is possible to proxy such requests. The same warnings
   provided in section .8 apply.

.  HTTP Headers

10.1.     AL Header

   AL = "AL" ":" 1*("<" AbsoluteURI ">") ; AbsoluteURI is defined in
   section 3.2.1 of [RFC2616]

   The AL header is an extension of the Location header. The contents
   of an AL header are ordered. If both a Location header and an AL
   header are included in the same request then the URI in the location
   header is to be treated as if it were the first entry in the AL
   header. The AL header MAY be used by itself but implementers should
   be aware that existing systems will ignore the header.

10.2.     mm Request Header

   mm = "mm" ":" Integer
   Integer = First_digit *More_digits
   First_digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
   More_digits = "0" | First_digit

   Indicates the minimum number of seconds that a multicast UDP HTTP
   resource MUST wait before it sends a response stimulated by a
   multicast request.

10.3.     mx Request Header

   mx = "mx" ":" Integer

   Indicates the maximum number of seconds that a multicast UDP HTTP
   resource MUST wait before it sends a response stimulated by a
   multicast request.

.  Security Considerations

   [Ed. Note: Besides putting in a note that all the normal HTTP
   security considerations apply we need to put in a discussion of the
   problems associated with requests getting lost as well as over sized
   request problem. We also need to talk about the fact that requests
   can get randomly lost. We also need to discuss how one uses


Goland                                                        [Page 4]

INTERNET-DRAFT                 UDP HTTP                  June 21, 1999


   authentication over UDP. Specifically, that one needs to assume the
   challenge and send the response as part of the request.]

.  Constants

   MAX_RETRIES - 3

   MIN_RETRY_INTERVAL - 0 second

   MAX_RETRY_INTERVAL - 10 seconds

.  References

   [RFC2119] S. Bradner. Key words for use in RFCs to Indicate
   Requirement Levels.  RFC 2119, March 1997.

   [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
   Masinter, P. Leach and T. Berners-Lee. Hypertext Transfer Protocol -
   HTTP/1.1. RFC 2616, November 1998.

.  Author's Address

      Yaron Y. Goland
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA 98052

      Email: yarong@microsoft.com

      This document will expire in September 1999.
























Goland                                                        [Page 5]