IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI

IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI

McDonald, Ira IMcDonald at crt.xerox.com
Fri Oct 26 15:53:44 EDT 2001


Hi Michael,

First, I suggest that any Subscription with a missing/empty
"notify-recipient-uri" MUST support retrieval of those 
notifications via IPPGET in-band and MAY support one or
more other client pull methods for notification retrieval.

Second, I agree that we have an ambiguity about WHICH are
the supported client pull methods, so how about a second
attribute (strictly alternate to "notify-recipient-uri",
so that one or the other MUST be in every Subscription),
called "notify-pull-method (1setOf keyword)", so that the
Printer attribute "notify-pull-method-supported" can enumerate
all the client pull methods supported by an implementation.

OK?

Cheers,
- Ira McDonald

-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Thursday, October 25, 2001 8:46 PM
To: McDonald, Ira
Cc: Hastings, Tom N; ipp (E-mail); IPP FAX DL (E-mail)
Subject: Re: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI


McDonald, Ira wrote:
> ...
> So let's just say that methods that are client pull (not server
> push) MUST NOT specify "notify-recipient-uri" in the Subscription
>  attributes group.
> 
> OK?

No argument here.

> PS - Recall that we can tell if IPPGET is supported (even though
> it MUST NOT appear in 'notify-uri-schemes-supported') because of
> 'operations-supported'.

Right, but that doesn't tell us what operation to use for a
specific subscription, right? :)

Currently we can say that if there is no notify-recipient-uri,
then use IPPGET and Get-Notifications for the subscription, but
what about other methods that might need the same treatment?

I know I'm nitpicking, but we need to make sure that the spec
addresses these issues so that future extensions (and there *will*
be more extensions I'm sure) can work together and not confuse
clients...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com



More information about the Ipp mailing list