I propose that we move further discussion of this to the SIP mailing list.
/a
On 1/1/09 10:52 PM, Mark Nottingham wrote:
Hi Adam,
Sorry for the holiday-induced delay.
On 13/12/2008, at 11:08 AM, Adam Roach wrote:
* Following on that thought, the idea behind the most recent Link
draft is to talk about link relations generically, and make Link
headers one use of them.
I understand what you're saying, but I'm somewhat sensitive to having
many optional ways of doing the same thing in the same protocol. In
my experience, you either end up with everyone supporting every way
of doing things (driving up implementation costs), or with people
selecting only their favorite mechanisms (driving down
interoperability). There is, of course, an unhappy medium between
those two extremes, in which you get both an increase in
implementation complexity and a decrease in interoperability (albeit
to a lesser degree).
I agree, and wasn't proposing that multiple discovery mechanisms be
called out (I see others drafts doing this and wince too); rather,
just that the door be left open for other ways to be used if someone
wants build on top of this in the future.
* 3.4 Subscription Duration -- just a thought, is it worth tying the
default subscription duration to the freshness lifetime of the HTTP
response (as defined by HTTP)?
I'm not sure. The goal behind selecting subscription durations is to
balance server load against time to recover in the case of a failure.
If you want to propose a concrete formula, I'll be happy to
incorporate it into the document, but I think it is of limited value.
I'm not sure enough of it to make a concrete proposal. I can
definitely see situations where the subscription lifetime varies
significantly, just wondering if it's better to use the expiry time as
a default, instead of baking in a (fairly arbitrary) number.
* 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.
* 3.5.2 - Why require an ETag or Content-MD5? Why recommend a
Last-Modified?
Philosophically: SIP Events, in general, reports the state of a
resource, not events that change its state (despite its name, which I
have grown to regret). It is true that state is usefully reported
when it changes, but thinking about it as the changes themselves
instead of the resultant state tends to put the cart before the horse.
Practically: without some means of tying the notification to the
resultant HTTP document, you end up with race conditions in which the
state of a document changes between retrieval and subscription to its
state. There are other ways to solve this race, but they're messy.
OK, that makes sense. Would you be comfortable making these
requirements a SHOULD (if they aren't already)?
[from a later message]
* Does the NOTIFY message include the URI of the resource that has
changed (didn't see it, but I may be missing something). It should
be added if not; otherwise, you're baking in a one-to-one
relationship between monitoring channels and http URIs. There will
be use cases where the receiver of the NOTIFY doesn't have enough
context to associate the message body you're sending with a URI.
Good point. How would you feel about adding a requirement to include
a "Link" header in the message/http body with a relation type of "self"?
Content-Location is probably more appropriate.
* The simplest and most efficient notification message to send is
"this resource has changed"; the client can then decide whether or
not to fetch an update, and combining any old response with a new
one is simple. It also assures that the subscribing client isn't
required to implement a cache. I would very much encourage you to
support this mode of interaction.
That is effectively what I'm trying to do; however, see my notes
above about race conditions. If a client doesn't want to cache
anything, they can simply treat each NOTIFY message as an indication
that the resource has (likely) changed. (They would still be well off
keeping track of the Content-MD5 and/or ETag for the brief period
between the HTTP operation and the SIP subscription just to make sure
the resource didn't change between those steps).
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.
* Conversely, if you are you intent on allowing transfer of an
entity with a notification, you may want to consider allowing the
transfer of multiple entities, to allow the use of content
negotiation (e.g., both an English and French representation under
the same URI, or a png and a gif). application/http would support this.
I'm ambivalent about allowing the inclusion of bodies in the
notifications. I would hesitate precluding future specifications from
doing so, but I'm not all that interested in developing a complicated
mechanism in this document that replicates the full set of HTTP
features (such as language and content negotiation).
I see. I didn't get that from reading the spec; my concerns were about
the more complex cases where people were trying to update headers and
bodies using the notifications (as above).
Perhaps the right thing to do is to have a very limited new media type
that communicates just a few things;
* URI (required)
* Content-MD5 (optional)
* ETag (optional)
* Last-Modified (optional)
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...)
Conneg definitely makes things more complex. I think that it's
legitimate to say that a notification applies to all representations
of a resource, and that you can't selectively send notifications for a
particular representation. The only sticky part here is that if there
*are* multiple representations for a resource, it's important for the
server to keep which one it's using for the ETag and/or Content-MD5
straight.
[responses to previous messages in thread]
...
That said, I agree that the draft shouldn't preclude other discovery
mechanisms, as mentioned above.
I'll reiterate my concerns about too many ways to do something. I'm
adding in the <link> and <atom:link/> mechanisms, but I'd hate to see
an explosion of mechanisms here, as it would make client
implementations untenably complicated.
Yes; see above.
Cheers,
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
