Mark:
Thank you very much for taking the time to look over the draft.
Responses inline.
/a
On 12/10/08 11:48 PM, Mark Nottingham wrote:
* "...it MUST return a Link: header..." seems like it's too strong;
servers may want to be selective about when they offer monitoring, and
there may be other ways to advertise it that are more appropriate.
It was certainly intended to be subject to policy -- I'll rephrase the
predicate to make this clearer.
* 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).
* "It MAY return both." is ambiguous; think you mean SIP + SIPS.
That is what I meant. I'll attempt to clarify.
* 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.
* 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.
* 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.
ETag and Content-MD5 form positive identifiers that the subscribing
party is able to associate with the resource when they retrieve it in
the first place. Content-MD5 has the benefit that it can be calculated
from a locally-cached value. Systems that are already using ETags for
other purposes can leverage the fact that they are already storing that
value with the resource.
The inclusion of Last-Modified had an appeal to me for optimizing
use-cases like this: I have a file on my file system that I know was
retrieved from a particular HTTP URL. The filesystem has a timestamp
associated with the file that represents the time it was downloaded. I
can compare this against the Last-Modified value much more cheaply than
I can generate an MD5 hash of its contents and compare that against the
Content-MD5. (Compare this behavior with the handling of the -N flag in
wget).
* 3.10 - limiting notifications to one a second makes sense also
because this is the granularity of time in HTTP.
Thanks.
[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"?
* 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).
* 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).
[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.
/a
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
