Graham,
Here is my second late response to you on an earlier message.
I think that a number of your issues in this message needs to be resolved in
the
QUALDOCS project rather than IPP, but see some answers in the text below.
Carl-Uno
> -----Original Message-----
> From: Graham Klyne [mailto:GK at Dial.pipex.com]
> Sent: Monday, August 02, 1999 6:27 AM
> To: ifx at pwg.org> Cc: ipp at pwg.org> Subject: IPP> draft-ietf-ipp-not-02.txt: IFX notes
>>> This message comments on the goals for IPP notification in
> the context of
> using IPP as a quality document transfer service (faxing).
>> I think we need to recognize a key distinction between:
>> + printing, which is primarily a presentation service, and
>> + faxing, which is primarily a communication service.
>> Many of the service components may be shared, but I take a
> view that the
> primary intents are different and that may lead to some
> differences in goals.
>> I think one of the key such differences is that faxing (as we
> know it) is
> primarily a two-party function, between sender and recipient.
> Printing
> (according to some of the scenarios in
> <draft-ietf-ipp-not-02.txt>) can be
> an N-party activity, and much of the scope of the
> notification goals seems
> to stem from this.
>> I think that a notification mechanism that satisfies the
> stated IPP goals
> will probably satisfy the IFX goals, but its functions may need to be
> restricted in order to match the needs of faxing.
>> #g
> --
>> >3 Requirements
>> [...]
> >2.It must be possible to support the IPP Notification interface using
> > third party notification services that exist today or that may be
> > standardized in the future.
>> In the context of faxing, I suspect the notification
> mechanisms used may
> need to be constrained to provide a common baseline mechanism.
Fine by me. We have discussed this for quite some time in IPP,
which is your favorite delivery transport?
>>> >3.A Job Submitting End User must be able to specify zero or more
> > notification recipients when submitting a print job. But
> don't expect
> > a submitter to be able to circumvent out of band subscriptions.
>> In the context of faxing, I'm not sure that 3rd party
> notifications are
> desirable; could this be used as a spamming tool?
Could be used as spamming tool, yes. Do you want to UNDO this feature in
QUALDOCS?
>> Also, could this create subtle covert channels for leaking information
> about corporate networks.
One solution that we have discussed is to send notifications back to the
initial HTTP/IPP client.
>> (The difference here between _Printing_ as a presentation function and
> _Faxing_ as a communication function is that in the
> _Printing_ case one may
> reasonably have a priori information about who can request printing
> services. This is not reasonable in the general faxing case.)
Not sure this really is a difference for IPP vs. FAX.
>> >4.When specifying a notification recipient, a Notification Subscriber
> > must be able to specify one or more notification events for that
> > notification recipient.
>> I think the range of notification events available to an
> unknown fax sender
> should be somewhat less than available to a known print job submitter.
Qustionable if this is a difference, see above.
>> >5.When specifying a notification recipient, the Notification
> Subscriber
> > must be able to specify either immediate or queued notification for
> > that notification recipient. This may be explicit, or
> implied by the
> > method of delivery chosen by the Job Submitting End User.
>> I think the mechanisms available in the faxing case should be
> pretty much
> the same as those available for sending the original message. In some
> respects, the original fax can be viewed as a kind of notification.
Don't understand what you mean by the last sentence. Does not make sense.
>> >6.When specifying a notification event, a Notification
> Subscriber must
> > be able to specify that zero or more notification attributes (or
> > attribute categories) be sent along with the notification,
> when that
> > event occurs.
>> Requested attributes: in the faxing case, should these be
> aligned with the
> kind of attributes available or considered for Internet fax [e.g.
> <draft-ietf-fax-dsn-extensions-01.txt>,<draft-ietf-fax-mdn-fea
> tures-01.txt>,
> RFC 2530].
I see this as part of the QUALDOCS requirements to specify.
>> >7.Common delivery methods, e.g. email, must be supported.
>> See comments on point 5 above.
>>> >8.There is no requirement for the IPP Printer receiving the print
> > request to validate the identity of an event recipient, nor the
> > ability of the system to deliver an event to that recipient as
> > requested (for example, if the event recipient is not at
> work today).
>> I don't think this is appropriate: in the case of faxing
> event receipients
> should be validated in some way (at least for requests in a
> job from an
> unknown submitter).
You want to mandate authentication for allclients? Otherwise,
how do you determine who is "unknown". How do you authenticate
email addresses in IFAX?
>> >9.However, an IPP Printer must validate its ability to
> deliver an event
> > using the specified delivery scheme. If it does not support the
> > specified scheme, or the specified scheme is invalid for
> some reason,
> > then it should respond to the print request with an error
> condition.
We will improve some of the wording.
>> In the faxing case, I suspect that fallback to a baseline
> mechanism might
> be more appropriate.
What do you define to be the baseline?
>>> >10. There must be a class of IPP event notification schemes
> or methods
> > which can flow through corporate firewalls. However, an IPP printer
> > need not test to guarantee delivery of the notification through a
> > firewall before accepting a print job.
>> Well, shouldn't ALL fax traffic be able to flow (in properly
> controlled
> fashion) through firewalls?
Fine, you can use email... Or allow IPP traffic through your firewall.
>> >11. A mechanism must be provided for delivering a
> notification to the
> > submitting client when the delivery of an event notification to a
> > specified Notification Recipient fails. (Optional? Or not
> necessary?)
> > Fall back means of subscribers determining if notifications have
> > failed. I.e. polling?
We will remove this.
>> I don't see this as a goal for faxing notifications.
>> >12. There must be a mechanism for localizing human consumable
> > notifications by the Notification Source.
> >
> >13. There must be a way to specify whether or not event delivery
> > requires acknowledgement back to the Event Source.
>> I commented on this in my response to IPP.
>> I think this would be especially problematic for a faxing application.
>> >14. There must be a mechanism to indicate the quality of service for
> > delivery of event reports. The policy must include stopping the
> > Printer and allowing the Printer to continue, when delivery of the
> > event report is not acknowledged. ISSUE: Should that policy be
> > specified by the Notification Subscriber (and authorized by the
> > Printer) or by the administrator in configuring the Printer?
>> Is this really compatible with using IPP for faxing?
See earlier message.
>> >15. There must be a mechanism so that job independent
> subscriptions do
> > not become stale and do not require human intervention to remove
> > stale subscriptions. However, stale must not be the inability to
> > deliver a notification report, since temporary event delivery
> > problems must be tolerated.
>> I would hope that constraints on the faxing case will take
> care of this
> automagically.
>> >4 Scenarios
> >
>> I think the scenarios here are not appropriate to faxing. Maybe some
> different set should be considered?
We are waiting for the QUALDOCS group to come up with those scenarios...
>>>> ------------
> Graham Klyne
> (GK at ACM.ORG)
>