[H-GEN] Does anyone have experience with the IETF process?
Bruce Campbell
bc at humbug.org.au
Mon Oct 16 21:25:35 EDT 2006
On Mon, 16 Oct 2006, Benjamin Carlyle wrote:
> G'day,
>
> http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt
>
> It is a draft for a subscription protocol based on HTTP. I would welcome
> draft. I would also welcome suggestions as to how to proceed from here.
Start at http://www.rfc-editor.org/ , and look for the guidelines
regarding the submission of internet drafts. If you are intending it as a
strawman, doing it as an individual draft would be the best.
> Does the world need this extension? I think so. There has been increased
> chatter about subscription and notification since work on atom
> concluded. There is talk particularly in financial markets about
> ensuring information is available in a timely and fair manner.
Ok, comments. What identifies a particular client? There is a basic
dialback mechanism designed to reduce instances of amplification attacks,
but when there are thousands of clients appearing to the server from one
IP address (eg, web proxy), what criteria does the server use to block
SUBSCRIBE requests until a successful notification has been performed?
Secondly, although presumably you intend that standard HTTP authorisation
mechanisms be used to determine access to a given resource, this needs to
be explicitly stated, lest your name be strung in effigy across multiple
mailing lists.
Thirdly, the time interval to expire subscriptions should be able to be
negotiated between the client and server, both in the SUBSCRIBE request,
and the NOTIFY response.
Fourthly, the examples need to properly identify the conversation flow;
ie, did the client say that, or did the server?
Fifthly, the DELETE command has already been used. See RFC2518, Webdav.
Sixthly, I do not think it is a good idea for the NOTIFY requests to
contain the full notification. For example, just say I use the dyndns
service to set up a subscription of a large dataset to a particular name
to my IP, eg, the call-back goes to http://evil.dyndns.example.org/notify
(1.2.3.4). I then point that name to another IP address, 4.3.2.1 . Your
server has just participated in a DoS against someone at 4.3.2.1 .
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.
> non-standard forms written several times. JEP-0060 is trying to
> standardise a subscription mechanism over XMPP, but is based on what I
> think are unworkable foundations when it comes to high volume
> internet-scale traffic.
I'd re-read JEP-0060 and associated discussion, and see what they've
covered regarding client identity and denial of service.
--==--
Bruce.
More information about the General
mailing list