W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1998

FW: Comments on ENP requirements draft

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Fri, 22 May 1998 14:58:05 -0700
To: WEBDAV WG <w3c-dist-auth@w3.org>
Message-ID: <003701bd85cc$b2bb8be0$d115c380@galileo.ics.uci.edu>
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
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
   * 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
   * 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC