IPP> Re: Notification Requirements document from the IPP WG - <http://www. ietf.org/internet-drafts/draft-ietf-ipp-not-03.txt>

IPP> Re: Notification Requirements document from the IPP WG - <http://www. ietf.org/internet-drafts/draft-ietf-ipp-not-03.txt>

IPP> Re: Notification Requirements document from the IPP WG - <http://www. ietf.org/internet-drafts/draft-ietf-ipp-not-03.txt>

Greg Hudson ghudson at MIT.EDU
Thu Aug 26 21:52:28 EDT 1999


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.



More information about the Ipp mailing list