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 at manros.com
> -----Original Message-----
> From: Harry Lewis [mailto:harryl at us.ibm.com]
> Sent: Tuesday, April 16, 2002 6:44 PM
> To: McDonald, Ira
> Cc: 'Mike Bartman'; 'Carl'; ipp at 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 at sharplabs.com>
> Sent by: owner-ipp at pwg.org> 04/16/2002 10:46 AM
>>> To: "'Mike Bartman'" <bartman at process.com>, "'Carl'"
> <carl at manros.com>
> cc: ipp at 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 at process.com]
> Sent: Tuesday, April 16, 2002 11:19 AM
> To: 'Carl'
> Cc: ipp at 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 at process.com>>>> > -----Original Message-----
> > From: Carl [mailto:carl at manros.com]
> > Sent: Tuesday, April 16, 2002 2:10 AM
> > To: Dennis Carney; ipp at 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 at manros.com> >
> > > -----Original Message-----
> > > From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf
> > Of Dennis
> > > Carney
> > > Sent: Monday, April 15, 2002 6:53 PM
> > > To: ipp at 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 at cp10.es To:
> > > "McDonald, Ira" <imcdonald at sharplabs.com>, Harry
> > > .xerox.com>
> > > Lewis/Boulder/IBM at IBMUS, "Hastings, Tom N"
> > > <hastings at cp10.es.xerox.com>
> > > Sent by: cc: Dennis
> > > Carney/Boulder/IBM at IBMUS, ipp at pwg.org> > > owner-ipp at 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 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> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>>>>