FW: Comments on ENP requirements draft

Caught by the spam filter.  I've added John to the accept2 list for the
mailing list.

- Jim

-----Original Message-----
From: John Stracke [mailto:francis@netscape.com]
Sent: Thursday, May 21, 1998 1:02 PM
To: WebDAV WG
Subject: [Spam?] Comments on ENP requirements draft


Hi, I'm a new member of Jim Cunningham's group here at Netscape; I'm
working on agents, so I read over the ENP requirements draft
(draft-ietf-webdav-enpreq-01.txt), and I had some comments on the
requirements list (section 4):

   * 4.2: "It SHOULD be possible to associate attributes with the
     notification request."  I'm afraid I don't quite see why--would
     they just be opaque data to be passed back to the client?
   * 4.3: queued notifications.  Sounds like email to me.  :-)
   * 4.4: notification with reliable delivery.  How important is it that
     order be preserved? I would think that, for most applications, it
     would suffice to provide guaranteed delivery with timestamps;
     receivers that need ordering can just sort the events.  (True, this
     doesn't solve the problem of "message 3 is useless without message
     2"--but that can be handled with application-level sequence
     numbers.)
   * 4.7: a consumer MUST be able to specify a list of other consumers
     to receive notifications.  This bothers me; it seems subject to
     spam-like abuse.  My feeling is that, if consumer A wants consumers
     X, Y, and Z to be notified, A should just forward the notifications
     itself.
   * 4.13: This follows from 4.15 and 4.17.
   * 4.14: What's an event channel? You haven't defined it.
   * 4.16: This is a subset of 4.18--copy&paste error?
   * 4.17: I'm not sure why this needs to be specified--any server
     should be able to handle multiple clients, and any client should be
     able to connect to multiple servers; the protocol doesn't normally
     have to worry about it.

Also, some thoughts on design (too early?): I believe that our best bet
would be to define the event format as a MIME type, so that events can
be carried in any MIME-bearing transport (mail, news, HTTP, Web push
protocols), rather than in a new notification delivery protocol.  This
would also let us get security by means of S/MIME.

One option would be to define a new report-type for multipart/report
(RFC1892), similar to DSN (RFC1894), since multipart/report is meant for
delivering event notifications.  This would simplify the work of making
sure that DSN can travel via the same notification protocols as ENP (as
Larry Masinter recommended back in January).

--
/==================================================================\
|John (Francis) Stracke    |My opinions are my own.| Due to        |
|Software Retrophrenologist|=======================/ circumstances |
|Netscape Comm. Corp.      | beyond your control, you are master of|
|francis@netscape.com      |  your fate, and captain of your soul. |
\==================================================================/
New area code for work number: 650

Received on Friday, 22 May 1998 17:57:20 UTC