IPP> draft-ietf-ipp-not-02.txt: IFX notes

IPP> draft-ietf-ipp-not-02.txt: IFX notes

IPP> draft-ietf-ipp-not-02.txt: IFX notes

Graham Klyne GK at Dial.pipex.com
Tue Aug 10 07:12:55 EDT 1999

At 18:59 09/08/99 -0700, Manros, Carl-Uno B wrote:
>I think that a number of your issues in this message needs to be resolved in
>QUALDOCS project rather than IPP, but see some answers in the text below. 

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 

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.


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



Graham Klyne

More information about the Ipp mailing list