Subject: IPP>MOD Concern about Event Notification Content

From: [email-masked] (Robert Herriot)
Date: Thu, 16 Oct 1997 18:23:34 -0700

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.  

I suggest that the format of this message should be in the IPP protocol
format so that the notification content can represent whatever the
protocol can represent.  Text in different languages is one thing
that comes to mind.

This means that for HTTP, the content would go as an application/ipp
entity in an HTTP request and we need a new IPP operation called "notify".

For email, it could go as a Multipart/alternative with one part 
text/plain whose content is specified but whose format is unspecified
and with another part which is application/ipp. Alternatively, we
could have two variants of email, one for human consumption and one
for machine consumption.

Although we may be too late in the process to solve this problem as I
have suggested, it is not too late to remove the specification of the
Event Notification Content so that we don't freeze a mistake.

Bob Herriot

---

From: Jay Martin <[email-masked]>
Date: Thu, 16 Oct 1997 22:02:18 -0400

I think it is way too late to get notification down *right* for
IPP v1.0, and therefore it should be removed altogether for v1.0
and put high on the list for v1.1 (or whatever we call the "next"
version of IPP).

	...jay

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 17 Oct 1997 10:04:19 PDT

>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: [email-masked]

---

From: Jay Martin <[email-masked]>
Date: Fri, 17 Oct 1997 14:20:58 -0400

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:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 17 Oct 1997 13:01:44 PDT

>run.  (That's not to say our SENSE implementation falls short,

Jay,

I am not looking for anything very sophisticated here, just the ability for
the end user to find out if a job completed correctly, or if not what
problems it ran into. You can get that with many of the existing printing
protocols already. And I claim that we already have the semantics for this
in place in our current draft document.

You can get very sophisticated and spend a long time on making the complete
and perfect notification service for operators administrators etc., the
messaging people in the IETF spent several years defining notifications,
and now they spend another few years on doing receipts. But, as I said
before I think that we have the semantics that we need for Version 1.0 of
IPP. 

What we need to improve is the format and to allow flexibility for
extensions in the next version of IPP. If we model that on what we alreay
have in the application/ipp, I cannot see this being a monumental task.

Carl-Uno
Carl-Uno Manros

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 17 Oct 1997 13:19:58 PDT

Oh,

I had one more response, which I did not put in the previous message.

>scenarios illustrating how IPP notification would actually work.

OK Jay,

Let me try to describe a little scenario on how I think this could work.

As before, the users specify their preferred language when submitting the job.

The IPP sever runs into some status change that the user has asked to be
notified about. The server then prepares the "application/ipp-notification"
MIME content, taking into account the user's language preference. The MIME
content is then sent over the protocol requested by the user and to the
address(es) specified at submission time. The notification in MIME format
arrives at the user's desktop and independently of how the notification got
delivered, is now associated with a little application that either
"translates" the content of the notification into a more user friendly
display format and pops up a window, or alternatively hands it over to a
log file, in which the user or an application can go and look for it at
their convenience.

Remember that we are only defining what goes over the protocol, we do not
have to go into detail about the user interface aspects, as long as we know
that there are several alternatives open.

Is this a reasonable scenario that you could go along with?

Carl-Uno

Carl-Uno Manros