HTTP Subscription Specification Was: [H-GEN] Does anyone have experience with the IETF process?

[Benjamin Carlyle]

On Tue, 2006-10-17 at 23:04 +1000, Benjamin Carlyle wrote:
> On Tue, 2006-10-17 at 03:25 +0200, Bruce Campbell wrote:
> > On Mon, 16 Oct 2006, Benjamin Carlyle wrote:
> > > http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt
> > Rather, the NOTIFY should simply indicate that the resource has been 
> > updated, and the client can then request it at its lesiure;  it may be 
> > something done under user direction.

I have incorporated this advice into the latest update (at the same
url). I think the biggest outstanding issue is probably the one of how a
notify resource comes to trust a notify source, especially over and
above other fake sources. This isn't such an issue with the EXPIRE
request option, but even this request allows for differnt kinds of
denial of service attacks by sending fake requests or not sending
requests at all.

I'm still mulling over whether or not this draft should attempt to
address the issue, or whether the trust relationship should be set up
out-of-band. There may be a conflict between the layered approach to
notifications and the prevention of interception and insertion by
mischevious entities. I could probably introduce a mechanism that
ensured the notify source does not change over the lifetime of a
subscription, but cracks and nastiness still abound. The end-to-end
nature of existing trust relationships also seem to work against the
concept of a caching web proxy.

I still have some JEP-0060 reading to do to contrast their approach.

Benjamin.