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.
>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?
Also, could this create subtle covert channels for leaking information about corporate networks.
(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.)
>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.
>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. >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-features-01.txt>, RFC 2530].
>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).
>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.
In the faxing case, I suspect that fallback to a baseline mechanism might be more appropriate.
>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?
>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?
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?
>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?
------------ Graham Klyne (GK@ACM.ORG)