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

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:

• 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.
• 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.
• I don't think MsgCreate/Message-ID belong in the URL any more than an eTag does.

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 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.

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.

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.

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.

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.

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.

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) 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.

Intellectual Property Statement

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.

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.

Disclaimer of Validity

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.

Copyright Statement

Copyright © 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.

Acknowledgement

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