Greg,
Thanks for taking time so quickly to respond. As you observed, some
notification delivery mechanisms will not make sense for certain type of
notifications, e.g. page level events, so we will need to specify which kind
of events can meaningfully be delivered by which protocol.
Your point on the need for further editing is noted, this was not intended
as the final version anyway.
Any chance that you will revisit the decision not to support MIME? Have you
nailed a maximum message size yet?
Carl-Uno
> -----Original Message-----
> From: Greg Hudson [mailto:ghudson at MIT.EDU]
> Sent: Thursday, August 26, 1999 6:52 PM
> To: Manros, Carl-Uno B
> Cc: impp at iastate.edu; IETF-IPP
> Subject: Re: Notification Requirements document from the IPP WG -
> <http://www. ietf.org/internet-drafts/draft-ietf-ipp-not-03.txt>
>>> I remember first hearing someone say that the IPP was "considering
> designing its own IM service for printer notifications," and like
> everyone else I thought, "what awful duplication." But after a little
> reflection, I realized that the problem is one of event notification,
> not of instant messages. Sometimes a user may want such notification
> to appear as an instant message (or a page, or an email message), but
> especially in the case of scenario 7, there isn't necesarily a lot of
> commonality between the two problems.
>> In fact, if you think about the problem hard enough, it almost becomes
> a better match for Presence Information than for Instant Messaging.
> But I don't think it's an especially good match for either.
>> But I'll set aside the philosophical issue for now, and look for
> practical problems as you requested.
>> > A couple of assumptions that we have made is that the protocol and
> > delivery destination can be expressed in a URL
>> Shouldn't be a problem. (I'm not saying the preferred form of an
> identifier is going to be a URL, but it should certainly be possible
> to express it as such.)
>> > and that the content of the message could be a MIME object.
>> We have a requirement that the message format "should be based on
> MIME." Note carefully the "should" and "based on." So this could be
> a problem, but might not be.
>> > Hope that somebody in your WG can find the time to check our
> > requirements document and give us feedback if you think IM could
> > provide a suitable delivery mechanism for us.
>> This document needs a lot of editing. In addition to a bunch of
> mechanical problems, there are some points of great inclarity; for
> instance, the first requirement is:
>> > 1.must indicate which of these requirements are REQUIRED and which
> > are OPTIONAL for a conforming implementation to support.
>> which makes no sense to me, since "these requirements" apply to the
> specification document and not to the implementation.
>> Most of the requirements have to do with the mechanics of setting up
> subscriptions on the printer, and don't impose any restrictions on the
> IM system used. I don't see any immediate problems with IPP
> specifying a way to make printers send IMs using whatever protocol we
> eventually standardize.
>> > the IPP protocol (which is mapped on top of HTTP),
>> I never understood this decision, incidentally, but this is not the
> right time or venue to argue it.
>