Mark:
I'm working on the next draft for this document, which I hope will
address the points you and Theo have raised so far. I'm still not
completely comfortable that I understand the body-type concerns -- some
qustions below.
On 1/1/09 10:52 PM, Mark Nottingham wrote:
On 13/12/2008, at 11:08 AM, Adam Roach wrote:
* 3.5.1 message/httpfrag -- did you consider using application/http
(defined in RFC2616)? I mention this because HTTP already defines
how to update a cache entry's headers based upon a HEAD or 304
response; it would be nice to reuse that if possible. Also, what
does making the status-line optional bring? The semantics of the
message would be clearer if it were required...
I'm hardly an HTTP expert -- so, on first glance, I feared that
re-using message/http would run afoul of semantic restrictions
associated with that content type (in the same way that omitting
critical header fields from a SIP message would make it invalid; that
is what drove development of the message/sipfrag content type).
If you think that re-use of message/http is kosher in this context,
then I'd be quite pleased to use that instead of defining a new
content-type. I strongly prefer re-use over re-invention.
The optional status-line feature was copied from message/sipfrag. It
has little value here, so I'm happy to make status lines mandatory.
Not message/http, application/http;
The application/http type can be used to enclose a pipeline of one or
more HTTP request or response messages (not intermixed).
I think this will work, provided that the status-line is mandatory.
Remember that a HEAD response is allowed to omit a body, so from the
purely syntactic standpoint, you should be OK if the body is missing.
However, see below.
I think I understand what you're saying here, but I have one remaining
point of confusion: why would I use application/http over message/http?
As things are currently defined, we won't have more than one HTTP
response conveyed in a single MIME part at a time.
...
OK. My concern is when the client does have a cached or otherwise
locally stored copy, and they need to combine it with a partial
response -- e.g., when the status code isn't present, or partial
headers are there, etc. This area is reasonably well-defined when used
inside of HTTP, but taken out of context, it doesn't hold up terribly
well.
I'm happy to specify that the body of the NOTIFY is a full set of HTTP
headers, if that satisfies your concern.
...
without the option for status-line, other headers or body, to avoid
the complexity. More advanced uses could use application/http (but you
wouldn't necessarily need to specify how to do this...)
I'd like to avoid defining a new syntax. In particular, I'd like to be
able to re-use standard HTTP parsers for the body, and we risk losing
that if we start crafting our own syntax definition.
/a
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
