IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15

IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Apr 15 14:26:16 EDT 2002


Harry,

I agree with Ira.  Furthermore, the advantage of having the client
conformance requirements (as well as the Printer conformance requirements),
is that a client implementor knows that his/her conforming notifications
implementation will interoperate with any Printer that is also a conforming
notifications implementation.

BTW, the reason that we didn't have client conformance requirements in the
original Notifications and Subscriptions spec, is because we didn't have
agreement on any REQUIRED Delivery Method for the Printer when it supports
Notification.  So now that we have agreement for the Printer, we can add
that requirement for the client (conditional on the client supporting
notifications at all). 

Tom

-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Monday, April 15, 2002 10:51
To: 'Harry Lewis'; Hastings, Tom N
Cc: Dennis Carney; ipp at pwg.org
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
Commen ts by April 15


Hi Harry,

To prove interoperability in protocols, the IESG always requires
conformance requirements for both Client and Server (Printer, in
our case).

But the requirement will be conditional:

If an IPP Printer supports notifications, then it MUST support
the 'ippget' in-band delivery method.

If an IPP Client supports notifications, then it MUST support
the 'ippget' in-band delivery method.

OK?

Cheers,
- Ira McDonald
  High North Inc

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Thursday, April 11, 2002 4:04 PM
To: Hastings, Tom N
Cc: Dennis Carney; ipp at pwg.org
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
Commen ts by April 15


I support mandating IPPGET for IPP notification but I believe the mandate 
should apply to the printer not the client. 

Architecturally, mandating support (for IPPGET) at the printer is 
sufficient to support complete interoperability. It is overkill to mandate 
both ends. For IPPFAX (a specific application of IPP) I agree we want to 
lock down the specification for every node. 

Are  you are saying that someone can build a client with (ex.) mailto 
notification support (only)... but they just can't claim it is an IPP 
client that supports notification? If someone chooses to do this, of 
course they run the risk of reduced interoperability. That is a conscious 
choice.  The architecture and specifications still fully support complete 
interoperability. 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




"Hastings, Tom N" <hastings at cp10.es.xerox.com>
Sent by: owner-ipp at pwg.org
04/10/2002 06:08 PM

 
        To:     Dennis Carney/Boulder/IBM at IBMUS
        cc:     ipp at pwg.org
        Subject:        RE: IPP> RE: Mandatory Delivery Method for
Notifications - Commen       ts 
by April 15

 

Dennis,

Yes, I was adding to Carl-Uno's proposal, because in order to get
interoperability between a client and a Printer you need to have 
conformance
requirements for both the client and Printer, not just the Printer.  The
reason we left out client conformance in the Notification spec was because
we didn't have any Delivery Method REQUIRED for the Printer, if
Notifications were supported.  But now the proposal is for the 
Notification
spec to REQUIRE the Printer to support (implement) the IPPGET Delivery
Method, if the Printer supports Notification.

However, I don't think that there is the problem that you think for adding
this client requirement.  My entire statement was:

2. REQUIRE that a client support the IPPGET Delivery Method, if it 
supports
IPP Notifications.

The "if ..." doesn't require clients to support (implement) Notifications.
But if a client does support (implement) IPP Notifications, then it MUST
support (implement) IPPGET Delivery Method and MAY support (implement)
others.  Then such a conforming client can interoperate with a conforming
Printer, including Notifications.  None of these statement require the
client to actually *use* Notifications, if the user doesn't want to.

OK?

Tom

-----Original Message-----
From: Dennis Carney [mailto:dcarney at us.ibm.com]
Sent: Wednesday, April 10, 2002 08:54
To: ipp at pwg.org
Cc: Hastings, Tom N
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
Commen ts by April 15



Tom,

I see a way in which your comments added a new wrinkle, although I may be
mistaken.  I didn't get the impression in the previous messages that we
were discussing mandating that a *client* support IPPGET if it supports 
any
notification mechanisms--I read Carl's "notification implementations" as
discussing IPP servers only.

What does it mean that a client "support" a mandatory notification
mechanism?  If the client has no interest in actually using that 
mechanism,
it doesn't make sense to force the client to implement it anyway, then 
just
not use it.  Am I missing something?

Dennis Carney
IBM Printing Systems




 

                      "Hastings, Tom N"

                      <hastings at cp10.es        To:       Carl
<carl at manros.com>

                      .xerox.com>              cc:       ipp at pwg.org

                      Sent by:                 Subject:  RE: IPP> RE:
Mandatory Delivery Method for Notifications - Commen       ts by April 15 
                      owner-ipp at pwg.org

 

 

                      04/09/02 07:32 PM

 

 




Carl-Uno,

I support the proposal to REQUIRE a Notification Delivery Method so that
interoperability between a conforming client and a conforming Printer is
enhanced for Notifications.

I also support the proposal to make IPPGET be that REQUIRED Delivery 
Method
by changing the IPP Notifications and Subscriptions document (which is an
OPTIONAL IPP extension document) in the following ways:

1. REQUIRE that a Printer support the IPPGET Delivery Method, if the
Printer
supports IPP Notifications.

2. REQUIRE that a client support the IPPGET Delivery Method, if it 
supports
IPP Notifications.

3. RFC 2910 already RECOMMENDs that a Printer support TLS, so saying the
same thing in the Notifications and Subscriptions document would be
redundant, but we could still do that.

Compared to our other two Delivery Methods (MAILTO and INDP), the IPPGET
Delivery Method has the following advantages:

a. it is the easiest Delivery Method to support
b. it is in-band so it doesn't create any additional firewall problems
c. it is also useful for LAN job submission (with no firewall)
d. it doesn't create any more administrative problems
e. it is REQUIRED for IPPFAX conformance.
f. and doesn't have any SPAM problems (since the job submitter is polling
and/or keeping a channel open for notification events).


The IPPGET spec also should be changed:

4. We should also change the IPPGET spec itself from its current
"RECOMMENDED" to "REQUIRED" as a Delivery Method for an IPP Printer to
support.

Tom

-----Original Message-----
From: Carl [mailto:carl at manros.com]
Sent: Saturday, March 30, 2002 13:30
To: Carl; ipp at pwg.org
Subject: IPP> RE: Mandatory Delivery Method for Notifications - Comments
by April 15


Resend, with spelling corrected etc. The earlier message slipped away
before
I had finished it.

All,

Ned Freed communicated in an earlier message to the IPP WG, that the IESG
found it unacceptable that we had not choosen ONE mandatory delivery 
method
for notifications. They would also like to see that delivery method 
mandate
the use of security.

As those of you who were around about two years ago remember, we could not
reach agreement about mandating any of the delivery methods.

However, in the meantime the members of the IPPFAX project in the Printer
Working Group has reached an agreement that they will require all IPPFAX
implementions to implement the 'ippget' delivery method, and it also
requires support for TLS security.

Hence, I would like to put up the following strawman proposal to the IPP 
WG
members to satisfy the IESG comments:

1) Change the main Notifiction document to require that 'ippget' delivery
MUST be included for all notification implementations, but any of the 
other
two methods can also be implemented as an option.
<draft-ietf-ipp-not-spec-08.txt>

2) Put that rule also into the three delivery method documents, so it is
crystal clear what the rule is.
<draft-ietf-ipp-notify-get-06.txt>
<draft-ietf-ipp-notify-mailto-04.txt>
<draft-ietf-ipp-indp-method-06.txt>

3) Further, in the 'ippget' delivery document, we specify that TLS 
security
MUST be supported.
<draft-ietf-ipp-notify-get-06.txt>

If we can reach agreement on this, I will instruct the IPP editor to
implement these changes.

I would like to get your reactions back on this proposal no later than
April
15, 2002.

Carl-Uno Manros
Chair of IETF IPP WG

10701 S Eastern Ave #1117
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-310-251-7103
Email carl at manros.com









More information about the Ipp mailing list