Subject: Re: IPP>MOD Concern about Event Notification Content

From: Scott Isaacson <[email-masked]>
Date: Mon, 20 Oct 1997 09:00:18 -0600

>From day one, we said that we were not going to define a new "nofication
protocol" for IPP and that for IPP/1.0 we would not define new "notify"
operations.  I want to adamantly stand by this.   We can not and should not
allow ourselves to get distracted by the absence of an messaging/event
service for the Internet.  As Jay has pointed out, this is something that
needs to be designed and architected.  Look at all the work that OMG COS
event has done and all of the non-open solution providers have done - this
is a big job and SHALL NOT be done as a "side effort" of the IPP working
group.

For the longest time we said "any supported URI scheme as the notification
method with unspecified content or format".  Then we said "boo, boo, ....,
broken, bad...."  and we started to say "any supported URI scheme with ONE
specified content format for all notification methods FTP, MAILTO, etc."  I
hope we can all agree that what we now got is still "boo, boo, ...., broken,
bad, ...."    

So we should retreat for 1.0, however still allow for some hooks (like we
have done for driver download and "more info") but not formally specify it. 
Just leave it as hooks that might work in some given implementations.  

I think that we should suggest somewhere what the mail-safe message might
look like.  

My comments below preceded by SAI>

Scott

>>> Robert Herriot <[email-masked]> 10/17 3:50 PM >>>

   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.

SAI> True, but why disallow it in an environment that may have client side
file
SAI> montoring already.  These should just be hooks to allow something
SAI> to maybe work, not full specifications of what to do with log file wrap
SAI> and overflow.

   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.

SAI> True, but why disallow it in an environment where the address is
SAI> not the client but a web server posting all event summaries?
SAI>  Again, these should just be hooks to allow something
SAI> to maybe work, not full specifications of what the back end of the
SAI> web server should do the event content.

   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.

SAI>  This is how we should word the suggested content for all forms of 
SAI> notification.

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.  

SAI> Perhaps allowing any supported URI with undefined content is 
SAI>  worth supporting

Scott

---

From: Tom Hastings <[email-masked]>
Date: Tue, 21 Oct 1997 08:54:19 PDT

I agree with Scott, and his replies to the other comments on notification,
that we need to define some hooks and that we don't need to define what a 
client (or some notification service that receives the notifications) looks 
like.

I'm against removing everything, and I think we can defined hooks in a way 
that we won't regret what we put into the standard.  I think we can salvage 
what we have with the following changes to the current text:

0. Sections 4.2.2 "notify-events" and 4.2.3 "notify-addresses" are
fine they way they are.

In Section 4.2.2.1 Notification Content:

1. We should RECOMMEND, but not require, which attributes 
SHOULD go in human readable messages.

2. We should RECOMMEND that the message SHOULD be in the
natural language that the client submits the job in.  

3. For the human readable messages, the syntax should be free form, 
rather than the specific format that we have in the text.

4. For the human readable messages, we should remove the charset 
specification, since the charset to use depends on the notification 
mechanism, not the charset of the client that is submitting the job.

5. Add "job-name" to the list of recommended attributes to include.
I'm getting annoyed with my current print notifications that just tell 
me the job number and not the job-name.  

6. For the mailto: scheme, add a note that a MIME attachment MAY be 
included for program consumption.

7. After V1.0, we should define a standard media (MIME) type to use as a
mail attachment and register it.  Since attachments are labeled, there 
won't be any conflict with any private types that implementors have defined.
If we define the standard type soon enough we may avoid proliferation
of private types.  

Comments?
Tom

---

From: Larry Masinter <[email-masked]>
Date: Tue, 21 Oct 1997 09:52:37 PDT

If event notifications are supplied in a multipart/alternative,
with, for example, the first part being the vendor's proprietary notification
format, and the second in text/plain, then
there will be a cleaner migration path than if only a single
part is expected by recipients of notifications.
-- 
http://www.parc.xerox.com/masinter

---

From: Tom Hastings <[email-masked]>
Date: Tue, 21 Oct 1997 10:20:54 PDT

Larry,

Building on your idea...

How about making your first part (vendor proprietary) be a mail attachment
in whatever media type the vendor wants or defines?

Make your second part be the text/plain body of the mail message 
and be human readable in any format (hopefully in the language of the 
user, but in a charset that the transport system can handle).

When the PWG agrees (soon after IPP V1.0) to a media type for notification
purposes, the Printer vendor can include that as an attachment as well.

If he had a proprietary media type, he can attach both as separate
attachments,
correct?

Then we have a good migration path as you urge, correct?

Tom

---

From: Larry Masinter <[email-masked]>
Date: Tue, 21 Oct 1997 15:26:43 PDT

Yes, that's how multipart/alternative works. It's for an
'attachment' that is available in multiple formats. You give
the same information in each form, but the reciever picks
the best (first) it can view. (The plain text version comes
last.)

Larry