IPP>MOD Concern about Event Notification Content

IPP>MOD Concern about Event Notification Content

Scott Isaacson SISAACSON at novell.com
Mon Oct 20 11:00:18 EDT 1997


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