[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          Y. Goland
Internet-Draft                                                       BEA
Expires: May 11, 2006                                   November 7, 2005


                  SOA-Reliability (SOA-Rity) for HTTP
                    draft-goland-http-reliability-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on May 11, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   SOAR-ity is intended to allow for "reliable" (this term is almost
   always a misnomer) messaging over HTTP.  It achieves this goal by
   introducing two new request headers, Message-ID which provides a
   unique ID for a message and MsgCreate which contains the date and
   time on which the first instance of the message with the associated
   Message-ID was sent.  The purpose of the Message-ID/MsgCreate pair is
   to allow any HTTP request (e.g. any HTTP method can be used) to be
   repeated multiple times with a guarantee that the message will be
   processed no more than one time.  In essence it makes any HTTP method



Goland                    Expires May 11, 2006                  [Page 1]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   call idempotent.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Making a Reliable Request over HTTP  . . . . . . . . . . . . .  4
   4.  Receiving a Response to a Reliable Request over HTTP . . . . .  4
   5.  OPTIONS Support  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Proxies & Caches . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   Appendix A.   Q&A  . . . . . . . . . . . . . . . . . . . . . . . .  9
   Appendix A.1. SOA-Rity?!?!!?!?!  . . . . . . . . . . . . . . . . .  9
   Appendix A.2. Why not put the MsgCreate/Message-ID values into
                 the URL? . . . . . . . . . . . . . . . . . . . . . .  9
   Appendix A.3. Why is there no time window declaration? . . . . . .  9
   Appendix A.4. Why introduce the MsgCreate Header? Why not just
                 use the HTTP Date header?  . . . . . . . . . . . . . 10
   Appendix A.5. Why use RFC 2234 ABNF instead of RFC 2616 ABNF?  . . 11
   Appendix A.6. Why not require RFC 2774 Support?  . . . . . . . . . 11
   Appendix A.7. Why Didn't You Use the Expect Header?  . . . . . . . 11
   Appendix A.8. What about Clockless Systems?  . . . . . . . . . . . 11
   Appendix A.9. What about One Ways? . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 13





















Goland                    Expires May 11, 2006                  [Page 2]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


1.  Introduction

   SOAR-ity is intended to allow for "reliable" (this term is almost
   always a misnomer) messaging over HTTP.  It achieves this goal by
   introducing two new request headers, Message-ID which provides a
   unique ID for a message and MsgCreate which contains the date and
   time on which the first instance of the message with the associated
   Message-ID was sent.  The purpose of the Message-ID/MsgCreate pair is
   to allow any HTTP request (e.g. any HTTP method can be used) to be
   repeated multiple times with a guarantee that the message will be
   processed no more than one time.  In essence it makes any HTTP method
   call idempotent.

   When a SOAR-ity message is recieved the MsgCreate value is checked to
   make sure the time/date is within the resource's current "time
   window".  So, for example, if the resource only remembers reliable
   messages for 10 hours then a MsgCreate value that is more than 10
   hours old is outside of the "time window" and has to be rejected.  If
   the MsgCreate value is within the time window then the resource will
   check to see if it has a record of the Message-ID value.  If it does
   then it will return a cached copy of the response it sent the first
   time it received this request.  If the Message-ID value hasn't been
   seen before then the resource will process the request and both send
   and cache its response.  It is the cached response that will be used
   if the request is ever repeated.

   The reader may benefit from reviewing both [ExactlyOnce] and
   [SoaReliableMessaging] to get more background on the motivation for
   SOA-Rity's design.


2.  Terminology

   The term resource is used in this specification instead of the more
   usual HTTP term server in order to indicated that the behavior
   specified by this specification can change on a resource by resource
   basis.

   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 [RFC2119].

   The HTTP header definitions are given using ABNF as defined in
   [RFC2234].







Goland                    Expires May 11, 2006                  [Page 3]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


3.  Making a Reliable Request over HTTP

   A reliable HTTP request MUST contain the following two headers:

   Header Name:  MsgCreate
   Header Value:  MsgCreate = "MsgCreate" ":" rfc1123-date ; the
      rfc1123-date production is defined by 3.3.1 of [RFC2616], note
      that when the production is used for the MsgCreate header it MUST
      provide its value in GMT
   Header Description:  Specifies the date and time when the first
      instance of a message baring the associated message ID was
      created.  This value MUST be reproduced with the same value on
      every instance of the message carrying the associated message ID.

   and

   Header Name:  Message-ID
   Header Value:  Message-ID = "Message-ID" ":" URI ; the URI production
      is defined by [RFC2396]
   Header Description:  A message ID specified as a globally unique URI
      that will make this message unique amongst all messages generated
      across all senders for all time.  It is recommended that
      implementers look at [RFC4122] as an easy way to meet the previous
      requirement.

   Example:

   POST /resource/foo HTTP/1.1
   Host: www.example.com
   Content-Type: text/xml
   MsgCreate: 14 Oct 2005 16:20:00 GMT
   Message-ID: urn:uuid:72dfcac0-3d09-11da-8cd6-0800200c9a66
   ...


4.  Receiving a Response to a Reliable Request over HTTP

   The SOARITY response header is used in responses in the manner
   specified in the rest of this section.

   Header Name:  SOARITY
   Header Value:  SOARITY = "SOARITY" ":" ("supported" / "unsupported" /
      "MsgCreate/Message-ID Rejected")
   Header Description:  Provides information about the resource's
      support for SOA-Rity.  The "supported" value is returned on all
      successful responses to confirm to the receiver that the resource
      has honored the SOA-Rity headers.  "Unsupported" appears on
      rejections to confirm that the receiver does not support SOA-Rity



Goland                    Expires May 11, 2006                  [Page 4]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


      for that sender at that time.  The "MsgCreate/Message-ID Rejected"
      value specifies that the combination of the submitted MsgCreate
      and Message-ID values have been rejected, the request SHOULD NOT
      be repeated with those values.

   If a resource receives a request with the MsgCreate header but not
   with the Message-ID header then the request MUST be rejected with a
   400 (Bad Request) response that MAY contain the SOARITY header with
   an appropriate (e.g. "supported" or "unsupported") value.  It is,
   however, legal to send a request with a Message-ID header but without
   a MsgCreate header, in that case the request MUST NOT be treated as
   requesting reliable delivery.  The reason for the difference in
   treatment is that the MsgCreate header is only intended for reliable
   messaging usage while the Message-ID header has potential utility
   outside of reliable messaging.

   If a resource receives a request with the SOA-Rity headers but
   chooses not to honor those headers (for whatever reason) then the
   resource MUST return a 412 (precondition failed) response with the
   SOARITY header set to the value "unsupported".  Clients who wish to
   make sure that their requests cannot be mistakenly processed
   unreliably on a request that included a demand for reliability by
   resources that do not support this specification should investigate
   [RFC2774].  Note, however, that this specification does not require
   that resources support [RFC2774].

   If the resource does support the SOA-Rity headers then the resource
   MUST first validate that the date/time specified in the MsgCreate
   header is not beyond the resource's time window for remembering IDs.
   If the value is beyond the resource's time window then the message
   MUST be rejected with a 403 (Forbidden) response with the SOARITY
   header set to "MsgCreate/Message-ID Rejected".

   If a request contains a MsgCreate and Message-ID header where the
   Message-ID has been seen previously but with a MsgCreate value that
   resolved to a different time/date then, assuming the MsgCreate value
   is within the current time window, the request MUST be rejected with
   a 403 (Forbidden) response with the SOARITY header set to "MsgCreate/
   Message-ID Rejected".

   The resource MAY assume that if it receives a message with a
   MsgCreate/Message-ID header combination it has seen before then the
   new request is identical to the previous request with the same
   MsgCreate/Message-ID values.  In other words if a client makes a
   mistake and repeats a MsgCreate/Message-ID pair on two different
   requests then the resource is under no obligation to detect this
   error.  Still, well behaved resources should at least validate that
   the HTTP method is the same (e.g. a GET and POST with the same



Goland                    Expires May 11, 2006                  [Page 5]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   MsgCreate/Message-ID values should be rejected) as well as the
   request body and key headers.  If a resource does choose to remember
   information about a request other than its MsgCreate/Message-ID pair
   then it MUST send a 400 (Bad Request) to any clients who use the same
   MsgCreate/Message-ID pair twice on two materially different messages.

   The term 'materially different' in the previous sentence is intended
   to indicate that not all headers need to be the same for two requests
   with the same MsgCreate/Message-ID values to be treated as identical.
   For example, the Date request header, the If-* headers, the Range
   header, the user-agent header, etc. could all be different on
   repeated requests but these differences are not 'material' in terms
   of stating that the repeated request with a specific MsgCreate/
   Message-ID pair is the same as the original request.

   A MsgCreate/Message-ID pair MUST be constrained to only apply to a
   specific authenticated requester when authentication is in use.

   If the MsgCreate is within the local time window then the resource
   MUST determine if this request has been answered previously.  If so
   then the resource MUST return the same response as the one it
   originally sent.  Note however that the term 'same' only applies to
   the response code and the body, the value of the headers may need to
   be altered in some cases although the default behavior should be to
   return the same header values as on the original response.

   If, for whatever reason, the resource cannot honor the requirement to
   return the same response then the resource MUST either return a 403
   (Forbidden) response with the SOARITY header set to "MsgCreate/
   Message-ID Rejected" (if the condition is permanent) or a 503
   (Service Unavailable) with a SOARITY header value of "supported" (if
   the condition is temporary).

   If-* and Range headers on repeated requests should be honored
   following the resource's normal policies (in the case of range) and
   HTTP's requirements (in the case of If-*).  Although these headers on
   a repeated request can cause a different response to be received than
   what was sent in response to the original request the alterations
   only affect the response body and not the original outcome of the
   method's processing.  In other words, if a client submits a POST
   using the SOA-Rity headers which generates a HTTP response body and
   then later repeats the POST but includes a Range request then the
   returned body (assuming the resource honors Range) would contain only
   the subset of the original response specified by the range.  But, the
   repeated response would just be a copy of the original HTML response,
   no new processing would occur and SOA-Rity's idempotent promise would
   be honored.




Goland                    Expires May 11, 2006                  [Page 6]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   If a resource that supports SOA-Rity receives a message whose
   MsgCreate is within the current time window and with a Message-ID
   that the resource has not previously seen then the response MUST
   respond normally to the request but the response MUST contain the
   SOARITY header set to "supported".

   The logic regarding the MsgCreate header requires that the clocks at
   the client and resource be reasonably synchronized.  As such to be
   compliant with this specification both a client and resource MUST
   have clocks and MUST take 'reasonable' actions to ensure those clocks
   are accurate.  Deploying and properly configuring a Network Time
   Protocol (NTP) client [RFC958] is an example of a 'reasonable' action
   to ensure a clock is accurate.  Note however that clocks, even with
   NTP, can still skew and messages can be delayed for non-trivial
   periods of time during network transmission, especially if
   intermediaries are involved.  Therefore resources are encouraged to
   be generous in the size of their time windows and clients are
   encouraged to be stingy in their expectations of how large the
   windows will be.

   Example:

   HTTP/1.1 200 It's all cool
   SOARITY: supported
   ...


5.  OPTIONS Support

   A resource that supports this specification MUST return the SOARITY
   header on an OPTIONS response with the value of either "supported" or
   "unsupported" depending on the resource's support for SOA-Rity for
   the particular client who made the request (assuming authentication
   is involved).  In other words, it is perfectly legal for a resource
   to send a SOARITY header with "supported" to one authenticated client
   and "unsupported" to a different authenticated client.


6.  Proxies & Caches

   Successful responses to reliable requests SHOULD include the HTTP 1.1
   Vary header with values that point to the Message-ID and MsgCreate
   headers.  Please refer to section 14.8 of [RFC2616] for details of
   how caching and shared caches interact in order to make sure that a
   private response is not inadvertently cached by a shared cached.






Goland                    Expires May 11, 2006                  [Page 7]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


7.  Security Considerations

   It is, in theory, possible for a client to repeat a request made by
   some other client but using the same Message-ID and MsgCreate values.
   If successful such an attempt would allow one client to see the
   response sent to another client.  A simple way to prevent such an
   attack is to authenticate all requesters and, when recording
   MsgCreate/Message-ID values, to also record the identity of the
   requester.  In the future if a request is received with the same
   Message-ID/MsgCreate values it will only be honored if the client is
   authenticated as the original sender.

   The provision of reliable messaging can entail the use of a non-
   trivial amount of resources.  As such large numbers of reliable
   messaging requests can constitute a denial of service attack.
   Therefore it is reasonable to only provide SOA-Rity support to
   authenticated requesters or to use other mechanisms to rate limit who
   can make requests.


8.  IANA Considerations

   The following HTTP headers are submitted for provisional message
   header field registration per [RFC3864].

   Header Field Name:  MsgCreate
   Applicable Protocol:  http
   Status:  provisional
   Author/Change controller:
      Name:  Yaron Y. Goland
      Email:  soarityietfsubmission@goland.org
      Home Page URI:  http://www.goland.org
   Defined In:  Section 3 of this document.

   Header Field Name:  Message-ID
   Applicable Protocol:  http
   Status:  provisional
   Author/Change controller:
      Name:  Yaron Y. Goland
      Email:  soarityietfsubmission@goland.org
      Home Page URI:  http://www.goland.org
   Defined In:  Section 3 of this document.

   Header Field Name:  SOARITY







Goland                    Expires May 11, 2006                  [Page 8]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   Applicable Protocol:  http
   Status:  provisional
   Author/Change controller:
      Name:  Yaron Y. Goland
      Email:  soarityietfsubmission@goland.org
      Home Page URI:  http://www.goland.org
   Defined In:  Section 4 of this document.


Appendix A.  Q&A

Appendix A.1.  SOA-Rity?!?!!?!?!

   O.k.  O.k.  I know, it's not the best name in the world.  Although I
   must admit that people I share it with either laugh or wretch when
   they hear it which is more or less the range of reactions I'm looking
   for. :) I thought about SOA-R but that sounds like sore.  I also
   thought about SOA-Ring but that seemed forced.  I'm open to better
   ideas.

Appendix A.2.  Why not put the MsgCreate/Message-ID values into the URL?

   When I was first designing the HTTP version of this protocol I
   thought of sticking the MsgCreate and Message-ID values directly into
   the URL.  E.g. something along the lines of:

   POST /resource/foo?MsgCreate=14Oct200516:20:00GMT&Message-ID=urn:
   uuid:72dfcac0-3d09-11da-8cd6-0800200c9a66 HTTP/1.1
   Host: www.example.com
   Content-Type: text/xml
   ...

   I changed my mind for a number of reasons:

   o  In theory URLs are supposed to be of unlimited length but in
      practice there are often size limits and the MsgCreate/Message-ID
      values are not small.
   o  There is no standard for how to place arguments on a URL so I
      would, in effect, be telling people "Your URLS MUST support a
      query option and MUST use the '&' character as a delimiter."  I
      generally don't like telling people how to form their URLs.
   o  I don't think MsgCreate/Message-ID belong in the URL any more than
      an eTag does.

Appendix A.3.  Why is there no time window declaration?

   It would be easy to throw in a header that specifies how long a
   service promises to remember messages but I think the value would be



Goland                    Expires May 11, 2006                  [Page 9]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   so misleading as to be, on balance, a bad idea.  First, servers crash
   and forget things (which they shouldn't, but oh well).  Second, a
   service may have different windows for different people at different
   times.  In truth the window value would at best be a 'rough estimate'
   rather than a real promise.  I suspect the best way to present time
   window information is as part of a human readable description of what
   the server is and how it works, this is exactly the sort of thing one
   should get back in an OPTIONS response.

Appendix A.4.  Why introduce the MsgCreate Header? Why not just use the
               HTTP Date header?

   It would be easy enough to just re-use the HTTP date header rather
   than introduce the MsgCreate header.  The main consequence would
   probably be to create a SOARITY request header to definitively
   identify a request as requiring SOA-Rity support.

   One could even argue that this is the correct path forward since
   [RFC2616] explicitly states that the semantics for the HTTP Date
   header are the same as the [RFC822] orig-date production which is
   used to specify the email Date header.  In email the idea of
   resending a message is a common one and two different date headers
   are provided, a Date header reflecting when the message was
   originally created and a separate Resent-Date header to identify when
   the message was retried.

   The problem is that while HTTP may have stated that its Date header
   was to have [RFC822] semantics in practice nobody I'm aware of has
   made it a habit of repeating HTTP requests (even idempotent ones)
   with the same date header as the original request.  In fact, I
   suspect if one were to ask most HTTP implementers what they thought
   the meaning of the HTTP Date header was they would probably answer
   "it provides the time the message was sent."  The concept that the
   time when the message was sent and the time when it was actually
   generated could be radically different (due to retries) hasn't been
   entertained before in HTTP requests (it is, of course, quite common
   in cached replies however).

   So the question is - if this specification were to replace the
   MsgCreate header with the Date header and simply mandate that all
   SOA-Rity requests MUST include a Date header ([RFC2616] makes them
   optional on requests) as well as a new SOARITY request header would
   anything break?  Would this confuse any proxies?  Screw up any
   servers?

   I just don't know so I have erred on the side of caution and
   introduced the MsgCreate header.




Goland                    Expires May 11, 2006                 [Page 10]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


Appendix A.5.  Why use RFC 2234 ABNF instead of RFC 2616 ABNF?

   My main reason is that I wanted to use Harald Alvestrand's ABNF
   parser, available at http://www.apps.ietf.org/abnf.html.  Near as I
   can tell the choice shouldn't be a big deal because the only
   substantive difference my cursory examination of [RFC2616]'s ABNF
   versus the IETF standard [RFC2234]'s ABNF is that [RFC2616] uses "|"
   to indicate "or" semantics while [RFC2234] uses "/".  If it turns out
   it matters then I'll just use the [RFC2616] format.

Appendix A.6.  Why not require RFC 2774 Support?

   Because in this case I think it's more trouble than it's likely
   worth.  If a client is really worried that the resource it's talking
   to doesn't support SOA-Rity then it can make an OPTIONS request.
   Yes, this still leaves open some race conditions but I just don't
   think they are common enough to justify requiring everyone to support
   RFC 2774.

Appendix A.7.  Why Didn't You Use the Expect Header?

   Because it's useless.  It shows a real failure in the IETF RFC
   vetting process.  HTTP/1.1 was explicitly required to be backwards
   compatible with HTTP/1.0 so if a 1.0 resource got a 1.1 request then
   all would be well with the world.  But the Expect header's
   functionality is "If you don't have this feature then fail this
   request".  Well, duh, HTTP/1.0 didn't have an expect header so a 1.0
   server would just ignore expect all together.  So much for
   guaranteeing failure.  So anyone who actually takes RFC 2616 at its
   word must conclude that the RFC is, in fact, not backwards compatible
   with HTTP/1.0 and therefore failed in its mission.  The right thing
   to do would be to remove the Expect header.  RFC 2774 showed the
   right way to support Expect style behavior and retain complete
   backwards compatibility with HTTP/1.0.

Appendix A.8.  What about Clockless Systems?

   There are a number of tricks that could be used to make this
   specification work with clockless systems but they all put an extra
   burden on those with clocks that I just don't think can be justified.
   If it should turn out that reliable messaging in clockless systems is
   a real world use case it will always be possible to come out with an
   extension to this protocol.

Appendix A.9.  What about One Ways?

   HTTP only knows about request/responses so the spec only addresses
   that.  If someone sends a one-way request (at the application level)



Goland                    Expires May 11, 2006                 [Page 11]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   then at the HTTP level they still have to send some kind of response.
   The tradition is that the response is just a 200 (O.K.) with no
   response body.  It is that 200 response that would be cached by the
   algorithm above.  So the point is that from SOA-Rity's perspective it
   doesn't care or need to know if a request is part of a synchronous
   request/response or a one-way at the application level, it all looks
   the same at the HTTP level.


9.  References

9.1.  Normative References

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

   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

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

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", RFC 3864, BCP 90,
              September 2004.

9.2.  Informative References

   [ExactlyOnce]
              Goland, Y., "How Should An Exactly Once SOA Reliable
              Messaging System Be Designed? -
              http://www.goland.org/exactlyonce", October 2005.

   [RFC2774]  Frystyk, H., Leach, P., and S. Lawrence, "An HTTP
              Extension Framework", RFC 2774, February 2000.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique Identifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC822]   Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
              TEXT MESSAGES", RFC 822, August 1982.




Goland                    Expires May 11, 2006                 [Page 12]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   [RFC958]   Mills, D., "Network Time Protocol (NTP)", RFC 958,
              September 1985.

   [SoaReliableMessaging]
              Goland, Y., "Does SOA Need A Reliable Messaging Protocol?
              - http://www.goland.org/soareliablemessaging",
              October 2005.


Author's Address

   Yaron Y. Goland
   BEA Systems Inc.
   999 North Northlake Way
   Seattle, WA  98103
   US

   Email: soarityietfsubmission@goland.org
   URI:   http://www.goland.org


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.



Goland                    Expires May 11, 2006                 [Page 13]


Internet-Draft     SOA-Reliability (SOA-Rity) for HTTP     November 2005


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

































Goland                    Expires May 11, 2006                 [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/