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