I agree -- that why I sent this as a separate message: the primary
intended audience was QUALDOCS.
The intent of this posting was to highlight some issues for QUALDOCS
consideration that might be different than IPP requirements.
>> >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?
I don't have one in mind at this stage -- I'd say it depends on other
elements of the solution. (By "faxing" in this context, I mean IPP faxing
rather than the broader view of faxing, so something that uses the same
protocol substrate may be appropriate.)
>> >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?
Again, I don't have a firm view (yet) -- I wanted to raise the issue.
I think it's possibly appropriate that any 3rd party notification mechanism
at least requires authorization or a priori knowledge of the requester, so
that it's not available to an arbitrary message sender.
>> 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.
That's not a 3rd party notification (by my meaning of the term), so no
problem there.
>> (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.
In a purely technical sense, this may be true. But, "When you have a
hammer ..."
In expected usage, I believe (without hard evidence) that there is a
difference between printing and faxing.
For a faxing application, I don't think there can be a general presumption
that the sender is known to the receiver for the application to be useful
to a wothwhile audience. I think this presumption can reasonably be made
for a printing application. (Of course, you at Xerox may have some
interesting forward-looking views on the nature of printing as an
application -- my mind isn't closed on this but I think it is a topic that
should not be brushed aside.)
(Note: I am not trying to argue that the technical mechanisms of IPP are
not appropriate, but just that they may need to be profiled in different
ways for different applications.) I think that the "no heavy lifting"
argument can still apply as far as implementation is concerned, but that
the protocol specification needs to take account of its intended usage.
>> >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.
Consider the debate about MDNs and privacy concerns in e-mail.
>> >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.
One use for traditional fax is to send a "notification" to somebody in
near-real-time. (e.g. "Your goods are ready for collection", etc.) I am
suggesting that because fax is a medium that can be used for this kind of
high-level notification, it might be appropriate to look to the same
technical mechanisms to provide notification of delivery. (In the case of
IPP, this suggests that an HTTP/IPP-based mechanism might be the way to
send notifications.)
>> >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.
Yup.
>> >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?
Not quite -- this is the "3rd party notification issue" (see above).
>> >9.However, an IPP Printer must validate its ability to
>> deliver an event
>> > using the specified delivery scheme.
[...]
>>
>> In the faxing case, I suspect that fallback to a baseline
>> mechanism might
>> be more appropriate.
>
>What do you define to be the baseline?
That's for the QUALDOCS spec to say. I am just suggesting that in the
faxing case there should be _some_ baseline that is supported by all
systems, so interoperability can be guaranteed.
>> >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...
Sure.
#g
------------
Graham Klyne
(GK@ACM.ORG)