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

From: [email-masked] (Robert Herriot)
Date: Thu, 16 Oct 1997 19:50:02 -0700

I agree with you. It is better to remove an incomplete feature
and do it correctly later, than to leave in a mistake.

My original email (below) suggested that removing the feature
might be the best option. 

Bob Herriot

> From [email-masked] Thu Oct 16 19:01:46 1997
> 
> 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
> 
> 
> 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.
> > 
> > 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: [email-masked] (Ira Mcdonald x10962)
Date: Fri, 17 Oct 1997 05:25:08 PDT

Hi Bob,

Good catch.  Tom Hastings and I also found that some "text"
attributes (like xxx-state-message) were being erroneously
conveyed in strict US-ASCII while we were working through
issues around the simplifications for localization that you
(Bob) proposed during Wednesday afternoon's IPP telecon.

I agree that we should either remove the Event Notification
content from the spec OR fix it to use IPP standard encoding
format.  Note however, that doing reverse HTTP (from a 
server TO a client) for notification is not a trivial
burden for clients to absorb.

We certainly have to fix it or remove it from IPP/1.0.

Cheers,
- Ira McDonald (outside consultant at Xerox)
------------------------ Bob's note -------------------------
>From [email-masked] Thu Oct 16 21:46:41 1997
Date: Thu, 16 Oct 1997 18:23:34 PDT
From: [email-masked] (Robert Herriot)
To: [email-masked]
Subject: IPP>MOD Concern about Event Notification Content
Sender: [email-masked]
Status: R

Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Fri, 17 Oct 1997 14:50:42 -0700

Jay, 

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 [email-masked] 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:   [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   --
> ----------------------------------------------------------------------
> 
> 
> Carl-Uno Manros wrote:
> > 
> > At 06:23 PM 10/16/97 PDT, Robert Herriot wrote:
> > 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: [email-masked]
Date: Mon, 20 Oct 1997 08:08:37 -0700 (PDT)

Asynchronous event notification.

This area is extremely difficult to pin down and implement,
in spite of what you might think.

1. Transport protocol to be used?
    TCP?  UDP?

2. Application protocol to be used?
  TCP:
   SMTP? HTTP? Totally new one?
  UDP:
   SMTP? Totally new one?

3. OK, assume that we decide to use mail.

   1. Use SMTP? ESMTP?
   2. What headers in the message?
   3. What is the format of the text?
   4. Security issues?
       Using IPP for mail bombs?

I think that quietly dropping notification until the next version of the
protocol makes good sense.

Patrick Powell

---

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 21 Oct 1997 09:55:31 -0700

It is clear to me that we are all running out of time and steam to do a MIME
definition for notifications as I previously suggested. I concur with
Scott's proposal to leave in the current hooks in anticipation of future
addition of a fully fledged notification service later.

If we are going to leave things undefined about how notifications might
actually get delivered to users in Version 1.0, I see no reason to limit
outselves to only e-mail. If we are going to be vague, let us be vague in a
consistent manner. This is in support of Scott's proposal.

Carl-Uno

At 08:54 AM 10/21/97 PDT, you wrote:
>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
>
>At 08:00 10/20/1997 PDT, Scott Isaacson wrote:
>>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 >>>
>>
>>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.
>>
>>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.
>>
>>SAI>  This is how we should word the suggested content for all forms of 
>>SAI> notification.
>>
>>us more in the future than we want.  
>>
>>SAI> Perhaps allowing any supported URI with undefined content is 
>>SAI>  worth supporting
>>
>>Scott
>>
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>          
>>
>>
>
>