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 - 02:10:36 EDT