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.