Internet DRAFT - draft-goland-http-reliability
draft-goland-http-reliability
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]
