IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

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

From: Carl (carl@manros.com)
Date: Tue Apr 16 2002 - 21:48:42 EDT

  • Next message: Dennis Carney: "RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15"

    Harry,

    The simple answer is that IETF requires this for any Standards Track RFCs.

    Carl-Uno

    Carl-Uno Manros
    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@manros.com

    > -----Original Message-----
    > From: Harry Lewis [mailto:harryl@us.ibm.com]
    > Sent: Tuesday, April 16, 2002 6:44 PM
    > To: McDonald, Ira
    > Cc: 'Mike Bartman'; 'Carl'; ipp@pwg.org; Dennis Carney
    > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    > Commen ts by April 15
    >
    >
    > Why are we even describing conformance w.r.t. notifications for
    > IPP? Makes
    > sense, to me, for IPPFAX - a concrete application of IPP - but not
    > necessarily for IPP which is more of a tool than a "solution".
    > ----------------------------------------------
    > Harry Lewis
    > IBM Printing Systems
    > ----------------------------------------------
    >
    >
    >
    >
    > "McDonald, Ira" <imcdonald@sharplabs.com>
    > Sent by: owner-ipp@pwg.org
    > 04/16/2002 10:46 AM
    >
    >
    > To: "'Mike Bartman'" <bartman@process.com>, "'Carl'"
    > <carl@manros.com>
    > cc: ipp@pwg.org
    > Subject: RE: IPP> RE: Mandatory Delivery Method
    > for Notifications - Commen ts by
    > April 15
    >
    >
    >
    > Hi Mike,
    >
    > You're confused. We are NOT making any notification method mandatory
    > for conforming IPP Clients.
    >
    > Only IPP Clients which CLAIM to conform to IPP Notifications must
    > implement 'ippget'. Your implementation and Dennis Carney's
    > implementation are both (I hope) fully conforming to the IPP
    > Protocol (RFC 2910) and Model (RFC 2911). So you are 'IPP v1.1
    > conformant'.
    >
    > OK?
    >
    > Cheers,
    > - Ira McDonald
    > High North Inc
    >
    > PS - Isn't the out-of-band email notification useful in your OpenVMS
    > environment? Certainly most of the UNIX/Linux print submission tools
    > (command line) let you set a flag for email notification.
    >
    > -----Original Message-----
    > From: Mike Bartman [mailto:bartman@process.com]
    > Sent: Tuesday, April 16, 2002 11:19 AM
    > To: 'Carl'
    > Cc: ipp@pwg.org
    > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    > Commen ts by April 15
    >
    >
    > I agree with Dennis' point, for what that's worth. I've pointed out once
    > or
    > twice in the past that not every IPP implementation is on a GUI PC, or
    > with
    > a user handy. Some, like ours (on OpenVMS), are part of the system's
    > printing software, and there are no users involved once a job is submitted
    > for printing. There is no reasonable way to implement any kind of
    > asynchronous notification about previous jobs, or need for a polled method
    > as part of the printing software. The OS's whole printing paradigm is
    > based
    > on the idea of a line printer, and once you've "printed" (i.e. sent) a
    > job,
    > it is *over*. The system forgets all about it, and moves on to the next
    > job. The printer symbionts don't even work at the job level...they work
    > with files, one at a time, and the part that we provide to handle the IPP
    > protocol only gets buffers one at a time from code that ships
    > with the OS.
    > A
    > separate application that is used the way LPQ is on Unix might be good,
    > but
    > the actual printing client doesn't need, and can't support, any sort of
    > job
    > notification arrangement. Doing so would badly break the printing system.
    >
    > We, like lots of others, would like to be able to say that we "support IPP
    > vX.X", but if the protocol includes mandatory things that aren't possible
    > in
    > our environment, we won't be able to do that. The fact that we support
    > every part of it that makes any sense in our environment, and can print
    > jobs
    > just fine using that portion, won't be good enough for some customers who
    > are buzzword oriented rather than capability oriented.
    >
    > Notification methods are good, but making them mandatory...for the
    > client...seems pointless (as Dennis makes a good case for), as well as
    > counter-productive to the idea of getting wide-spread acceptance. For
    > servers, sure, but not for clients. Make it a part of the protocol, so
    > that
    > those that can benefit from it can use it, but to say that anyone who
    > can't
    > use a non-essential like notification isn't compliant is going too far.
    > IPP
    > 1.0 mandated support for sending a file, but it made sending multiple-file
    > jobs optional. This made sense...you can't print at all if you can't at
    > least send a file, but sending multi-file jobs isn't necessary to getting
    > something printed. Only that which is essential to the basic task should
    > be
    > mandatory. Those frills that are nice, but not essential to the basic
    > task,
    > should be optional...either "should" or "may", but optional.
    >
    > Thank you for listening to one implementer's opinion.
    >
    > -- Mike Bartman
    > Process Software
    > bartman@process.com
    >
    >
    >
    > > -----Original Message-----
    > > From: Carl [mailto:carl@manros.com]
    > > Sent: Tuesday, April 16, 2002 2:10 AM
    > > To: Dennis Carney; ipp@pwg.org
    > > Cc: 'Harry Lewis'; Hastings, Tom N; McDonald, Ira
    > > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    > > Commen ts by April 15
    > >
    > >
    > > Dennis,
    > >
    > > The whole idea about about IETF communication standards is to make
    > > interoperable implementations from a number of different vendors.
    > >
    > > To achieve interoperability you need to have something that
    > > is common among
    > > several implementations or you have no interoperability. You
    > > can implement
    > > additional optional stuff if you think that your customers have great
    > > interest in the options.
    > >
    > > BTW, nobody is twisting your arm if you happen to launch a
    > > product that
    > > isn't fully compatible with the standards, as long as you are
    > > not making
    > > such claims if they are not true. An common example is the
    > > implementation of
    > > HTTP. To my knowledge there is still no browser
    > > implementation that is fully
    > > conformant with the IETF HTTP spec, although Godzilla and
    > > Opera is getting
    > > close. Browser vendors instead have kept on adding private
    > > extensions rather
    > > than aiming for full alignment with the standard or claiming
    > > conformance
    > > with it. Not that I am recommending this behavious for IPP,
    > > but that is part
    > > of the real world out there.
    > >
    > > Carl-Uno
    > >
    > > Carl-Uno Manros
    > > 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@manros.com
    > >
    > > > -----Original Message-----
    > > > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf
    > > Of Dennis
    > > > Carney
    > > > Sent: Monday, April 15, 2002 6:53 PM
    > > > To: ipp@pwg.org
    > > > Cc: 'Harry Lewis'; Hastings, Tom N; McDonald, Ira
    > > > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    > > > Commen ts by April 15
    > > >
    > > >
    > > >
    > > > So, let's say I have an IPP client that does not have a
    > > status GUI (job
    > > > submitter only); or an IPP client that implements status,
    > > but does it by
    > > > polling.
    > > >
    > > > Then I see the notifications drafts and I think that a nice
    > > > option to allow
    > > > my users is that if the printer supports e-mail notifications, I
    > > > will allow
    > > > them to give me their email address and I will register
    > > them for email
    > > > notifications.
    > > >
    > > > However, my client cannot claim to be an "IPP notifications
    > > compliant"
    > > > client because it hasn't implemented ippget. So to become
    > > compliant, I
    > > > must "implement"/"support" ippget, *even if* my client is
    > > not going to use
    > > > it? Hmmm, so since I'm not going to use it, I guess I
    > > don't have to test
    > > > my implementation very hard. But come to think of it, if
    > > I'm not going to
    > > > use it, no one can actually tell (by sniffing or any other
    > > method) whether
    > > > I have implemented it correctly (they can tell I didn't use
    > > it, but can't
    > > > tell whether my unused implementation code works or not). So I
    > > > guess I can
    > > > just claim I support ippget--no one can prove me wrong!
    > > >
    > > > This is what I'm trying to get at when I wonder what it
    > > means to force a
    > > > client to support something. Each client uses the interfaces
    > > > necessary for
    > > > it to get its job done. Forcing it to issue ippget calls then
    > > > simply throw
    > > > out the results, just so it can be compliant and have the
    > > buzzwords on its
    > > > marketing material, seems to be a mistake to me.
    > > >
    > > > Dennis Carney
    > > > IBM Printing Systems
    > > >
    > > >
    > > >
    > > >
    > > > "Hastings, Tom N"
    > > >
    > > > <hastings@cp10.es To:
    > > > "McDonald, Ira" <imcdonald@sharplabs.com>, Harry
    > > > .xerox.com>
    > > > Lewis/Boulder/IBM@IBMUS, "Hastings, Tom N"
    > > > <hastings@cp10.es.xerox.com>
    > > > Sent by: cc: Dennis
    > > > Carney/Boulder/IBM@IBMUS, ipp@pwg.org
    > > > owner-ipp@pwg.org Subject: RE: IPP>
    > > > RE: Mandatory Delivery Method for Notifications - Commen
    > > > ts by April 15
    > > >
    > > >
    > > >
    > > > 04/15/02 12:26 PM
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > > 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@sharplabs.com]
    > > > Sent: Monday, April 15, 2002 10:51
    > > > To: 'Harry Lewis'; Hastings, Tom N
    > > > Cc: Dennis Carney; ipp@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@us.ibm.com]
    > > > Sent: Thursday, April 11, 2002 4:04 PM
    > > > To: Hastings, Tom N
    > > > Cc: Dennis Carney; ipp@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@cp10.es.xerox.com>
    > > > Sent by: owner-ipp@pwg.org
    > > > 04/10/2002 06:08 PM
    > > >
    > > >
    > > > To: Dennis Carney/Boulder/IBM@IBMUS
    > > > cc: ipp@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@us.ibm.com]
    > > > Sent: Wednesday, April 10, 2002 08:54
    > > > To: ipp@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@cp10.es To: Carl
    > > > <carl@manros.com>
    > > >
    > > > .xerox.com> cc: ipp@pwg.org
    > > >
    > > > Sent by: Subject:
    > > RE: IPP> RE:
    > > > Mandatory Delivery Method for Notifications - Commen
    > > ts by April 15
    > > > owner-ipp@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@manros.com]
    > > > Sent: Saturday, March 30, 2002 13:30
    > > > To: Carl; ipp@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@manros.com
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > > >
    > >
    > >
    >
    >
    >
    >



    This archive was generated by hypermail 2b29 : Tue Apr 16 2002 - 21:49:23 EDT