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