Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]
Mark Nottingham <mnot@mnot.net> Thu, 11 December 2008 06:54 UTC
Return-Path: <bliss-bounces@ietf.org>
X-Original-To: bliss-archive@optimus.ietf.org
Delivered-To: ietfarch-bliss-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E124D28C1E7; Wed, 10 Dec 2008 22:54:54 -0800 (PST)
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689EF3A6C17 for <bliss@core3.amsl.com>; Wed, 10 Dec 2008 21:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.925
X-Spam-Level:
X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=-2.326, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEbuG7z3nf4T for <bliss@core3.amsl.com>; Wed, 10 Dec 2008 21:57:55 -0800 (PST)
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 14F6D3A6859 for <bliss@ietf.org>; Wed, 10 Dec 2008 21:57:54 -0800 (PST)
Received: from [192.168.1.4] (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C189923E3E1; Thu, 11 Dec 2008 00:57:46 -0500 (EST)
Message-Id: <CB9E0E83-C7C2-4E28-829F-D66502090E59@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Adam Roach <adam@nostrum.com>
In-Reply-To: <4D3036ED-3CDC-4FEE-ABB1-AE2D341AA3FC@mnot.net>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 11 Dec 2008 16:57:44 +1100
References: <4925F054.5020205@nostrum.com> <167dfb9b0811201703i3162dbbbpabfc085ccef6754b@mail.gmail.com> <4926351B.6000907@nostrum.com> <167dfb9b0811210007q46e938b3y9d1f9589b271bed6@mail.gmail.com> <4926D995.2010508@nostrum.com> <4D3036ED-3CDC-4FEE-ABB1-AE2D341AA3FC@mnot.net>
X-Mailer: Apple Mail (2.929.2)
X-Mailman-Approved-At: Wed, 10 Dec 2008 22:54:53 -0800
Cc: bliss@ietf.org, Theo Zourzouvillys <theo@voip.co.uk>
Subject: Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http-subscribe-00.txt]
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: bliss-bounces@ietf.org
Errors-To: bliss-bounces@ietf.org
Three more; * 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. * 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. * 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. Cheers, On 11/12/2008, at 4:48 PM, Mark Nottingham wrote: > Sorry for the delay, finally off the road and had a chance to read. > > Overall I like this document a lot, and I think it should be easy to > align its use of the 'monitor' link relation with the Atom-over-HTTP > protocol described in draft-nottingham-http-cache-channels. > > A couple of comments / concerns: > > * "...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. > > * 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. Another use of them is in draft-nottingham- > site-meta (which is still under pretty active revision); this would > allow you to advertise a monitoring endpoint for your whole site, > for example. > > * "It MAY return both." is ambiguous; think you mean SIP + SIPS. > > * 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)? > > * 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... > > * 3.5.2 - Why require an ETag or Content-MD5? Why recommend a Last- > Modified? > > * 3.10 - limiting notifications to one a second makes sense also > because this is the granularity of time in HTTP. > > Specific responses below; > > > On 22/11/2008, at 2:53 AM, Adam Roach wrote: >> On 11/21/08 2:07 AM, Theo Zourzouvillys wrote: >>> On Fri, Nov 21, 2008 at 4:12 AM, Adam Roach <adam@nostrum.com> >>> wrote: >>> >>>> Very interesting proposals. Admittedly, for the use cases SIP is >>>> most >>>> interested in, the results are not typically HTML, but the idea of >>>> communicating these in the body may have merit. I'm curious about >>>> which use >>>> cases you have in mind -- do you imagine that there will be >>>> circumstances >>>> under which the HTTP server will have the ability to notify other >>>> nodes of >>>> changes, but not have the ability to include a Link: header? >>>> >>> >>> absolutely - perhaps a resource hosted on a CDN, where you commonly >>> can not send custom headers. > > You certainly can, in a cache-driven CDN (e.g., Akamai); the cases > where you can't aren't really CDNs as the industry understands them, > they're Web hosting farms (because they use replication; e.g., > Amazon's new service, if I read it correctly). In that case, > providing a channel without coordination with them can be harmful, > because you can get into race conditions where you send the > notification before the content is fully replicated. > > More to the point, if you're using a CDN (of either type), the most > likely value-add scenarios are using a monitoring channel to notify > the CDN itself of changes, and also the CDN providing a monitoring > server as a service. > > >>> or a blog, which may be hosted on some other platform (for example, >>> blogger.com) where you can edit the HTML but not the headers. > > I'm getting somewhat exasperated at how often this argument comes up > in specification discussions; to date mostly at the W3C. If we > follow it to its conclusion, the only Internet protocols that we can > develop are those that work with free hosting sites that only > provide FTP access. Surely the Internet and the Web shouldn't be > held hostage to them. > > That said, I agree that the draft shouldn't preclude other discovery > mechanisms, as mentioned above. > >>> the Link header as defined in draft-notthingham-http-link-header >>> itself is only a way of representing the <link> header in HTML and >>> <atom:link/> header in atom entries outside of the content where >>> it is >>> not possible because the content-type does not have support. So it >>> already "just works" by creating a link registry entry, however >>> would >>> be good to explicitly point out that it could be anywhere a link >>> relation is allowed. >> >> That's interesting -- Mark, do you have any input on the topic? > > I'm having trouble parsing the above -- is the concern that some > people might believe that any link in the headers *has* to be > mirrored in the content? If so, that's the first time I've heard > this brought up, and it certainly isn't the intent. We can clarify > if necessary. > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss
- [BLISS] [Fwd: I-D Action:draft-roach-sip-http-sub… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Theo Zourzouvillys
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Theo Zourzouvillys
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Theo Zourzouvillys
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Elwell, John
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Theo Zourzouvillys
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Theo Zourzouvillys
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Mark Nottingham
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Mark Nottingham
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Mark Nottingham
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Mark Nottingham
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach
- Re: [BLISS] [Fwd: I-D Action:draft-roach-sip-http… Adam Roach