Mike,
If you want to be exact in claiming conformance to anything in IETF you need
to say to which RFC(s) you are conforming.
Professional customers will ask you for this I am sure.
But I think it is quite OK to say that you are IPP/1.1 conformant if you
conform to RFCs 2910 and 2911, but if you additionally conform to the future
RFCs for IPP Notifications, you need to add that as a separate conformance
statement for your product, as that is an optional addition to the base IPP.
The same goes for a number of other optional IPP extensions, which might be
included in some products, but not others.
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 Mike
> Bartman
> Sent: Tuesday, April 16, 2002 9:57 AM
> To: 'McDonald, Ira'
> Cc: ipp@pwg.org
> Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
> Commen ts by April 15
>
>
> Ok.
>
> This does raise some confusion (on the part of customers) about what "IPP
> RFC compliant" might mean. We claim "IPP 1.0 RFC compliance" at
> the moment,
> because we support all of the mandatory, and a lot of the optional, things
> from the IPP 1.0 RFC set. This will change to 1.1 at some point (so far I
> haven't seen many printers that do much more than 1.0...and most don't do
> much of that so there hasn't been a big push for it). When we say that,
> some customers may assume that that includes everything, notification
> included, since, "it's all IPP, right?". For those in the IPP PWG it's a
> fuzzy term, and they would use actual RFC numbers, but marketing and
> customers aren't like that...they just say "IPP", and even getting them to
> use a version number can be hard...RFC numbers are out of the question.
>
> Still, that's not really the problem of the RFC creators, and I do
> understand your point about "if you support it at all, you have to support
> this way, but you don't have to support anything". We won't be "IPP
> Notification Compliant", but we will be "IPP V1.0 compliant", and
> will have
> to worry about other bits and pieces, and educating our customers
> about IPP,
> later I guess.
>
> Thanks for the clarification.
>
> -- Mike Bartman
> Process Software
> bartman@process.com
>
>
>
> > -----Original Message-----
> > From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> > Sent: Tuesday, April 16, 2002 12:47 PM
> > To: 'Mike Bartman'; 'Carl'
> > 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 - 14:21:43 EDT