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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>