I think that you have raised some excellent points. While I agree with
Carl-Uno that notification is important, the model document currently
has an incomplete solution which cannot be made complete with a few
small tweaks at the last minute. I do not think it is worth delaying
IPP a few more months to get notification correct and I don't want to
leave the existing wording in place.
The current proposal has several problems:
1) the content is specified in yet another protocol format. We
don't need that. It just allows us to have two protocols
to solve each problem in.
2) the target schemes and their uses are not well thought out:
ftp: I don't think that ftp appending-to-a-file is useful for a client.
What on the client is supposed to monitor this and clean up
the file when it gets too big.
http: this presumes a client http server or some other mechanism we
haven't thought through. Using application/ipp with a new
"notify" operation makes the most sense in this case. But
we haven't thought through how a client would plug into this
or how a client listens to HTTP.
mailto: this could be supported with free form text having certain
suggested attribute values. It's not the most useful
notification method, but it would work for human consumption.
Notification adds up to a lot of good, but incomplete ideas. They don't
belong in a standard that we will (hopefully) live with for many years.
Perhaps mailto with an undefined human readable format is worth
supporting in order to have notification, but even that may constrain
us more in the future than we want. But if the group consensus is that
we shouldn't toss out all notification from version 1.0, I could live
with just mailto and free-form unspecified text. All the rest would
take a lot more time to resolve and I don't think we have the time.
Bob Herriot
> From jkm@underscore.com Fri Oct 17 11:35:44 1997
>
> Carl-Uno,
>
> You're correct in that it probably won't take much time to hack
> up the existing text to nail down some kind of encoding that would
> be palatable to the IESG or whomever.
>
> That is not what concerns me about IPP notification, however.
> What does concern me is that no one has offered up any REAL
> scenarios illustrating how IPP notification would actually work.
>
> Sure, people have made comments to the effect of "just send an email
> message". But I think we really need to walk thru multiple (not
> just one) method of using IPP notification data to ensure that the
> resulting facility is indeed useful as designed.
>
> Do I have any suggestions? Not at this time...which is one reason
> I suggested we defer this entire capability until the next version
> of IPP.
>
> Event notification is NOT something we want to take lightly, nor
> do a half-baked job. Believe me, after spending the last 2 years
> on SENSE development, it's pretty easy to hack together a "solution"
> that appears to be useful, but ultimately falls short in the long
> run. (That's not to say our SENSE implementation falls short,
> mind you... ;-)
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>
>
> Carl-Uno Manros wrote:
> >
> > At 06:23 PM 10/16/97 PDT, Robert Herriot wrote:
> > >I just noticed that the IPP model document now has an Event Notification
> > >Content attribute whose format is US-ASCII even though it is intended
> > >for machine consumption.
> > >
> > >I am concerned about freezing this format into the standard because
> > >I think that it is a mistake.
> >
> > Bob and others that have responded to Bob's message,
> >
> > My view is that it would be highly undesirable to just take out the whole
> > concept of notifications, about which we have had general agreement right
> > from the start of the project. Also, trying to leave out the format
> > specification while keeping the attributes etc., I do not think is going to
> > fly when the IESG reviews the document. Looking at the actual text that we
> > are discussing, it seems that there are about 30 lines of text starting
> > with line number 1752 (from the PDF version of Scott's latest draft).
> > Reading through that, I think that we have most of the right semantics in
> > there already, except for an inconsistent statement about the use of ASCII.
> > We should not throw out the baby with the bath water!
> >
> > My suggestion is to rewrite the text in these 30 lines and instead create
> > an additional MIME type called "application/ipp-notification", which
> > contains the right language and encoding for I18N in the right places,
> > building on what we currently have. This MIME type could be carried in
> > SMTP, over HTTP, or other protocols.
> >
> > This does not seem such a major job. I do not think it would be a problem
> > to work out the details within a week.
> >
> > Comments? Volonteers?
> >
> > Carl-Uno
> >
> > Carl-Uno Manros
> > Principal Engineer - Advanced Printing Standards - Xerox Corporation
> > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> > Phone +1-310-333 8273, Fax +1-310-333 5514
> > Email: manros@cp10.es.xerox.com
>