IPP>MOD Concern about Event Notification Content

IPP>MOD Concern about Event Notification Content

Carl-Uno Manros carl at manros.com
Tue Oct 21 12:55:31 EDT 1997


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 <Robert.Herriot at Eng.Sun.COM> 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
>>
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>          
>>
>>
>
>



More information about the Ipp mailing list