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
Thu Oct 25 19:43:35 EDT 2001


Hi Michael,

Agreed - the proliferation of option (2) below (many booleans) would be
awful.

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?

Cheers,
- Ira McDonald

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'.

-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Thursday, October 25, 2001 12:45 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:
> ...
> Doesn't the empty string do that, too? :)
> 
> <ira>
> No - the empty string says there is NOT a destination for Printer
> pushed notifications.
> </ira>

Hmm, then we'd be better off specifying that an IPPGET subscription
should not specify a recipient then, right? :)

> ...
> (1) Redefine 'notify-recipient-uri' to allow empty string
> to indicate "client fetches notifications in-band via IPP or
> out-of-band by some non-IPP protocol".

See my comment above...

> (2) Add a new boolean operation attribute and Subscription
> Description attribute such as 'notify-ippget' (method
> specific, as we already did with email notifications)
> that is an ALTERNATIVE to the presence of 'notify-recipient-uri'
> in the Job Creation operation and on the Subscription object.

I really, really, really, really, (really!) don't like this
approach.  It fosters so much bloat and non-standardization it
isn't funny.  Imagine a couple dozen of these "notify-xyz"
attributes floating around, with no interoperability.

*If* we need to have an extra attribute to indicate the type
of subscription, it should be something generic like "notify-scheme"
which refers to the method name (usually the URI scheme name, but
"ippget" for IPPGET, etc.) so that future additions don't involve
attribute creep.  It also neatly sidesteps the IETF registration
issue with "ippget".

In short, here is my proposal:

    1. Add a notify-scheme (type2 keyword) attribute to the
       notification spec.  This will be a REQUIRED subscription
       attribute (i.e. returned with Get-Subscriptions or
       Get-Subcription-Attributes)...
    2. REQUIRE *either* notify-recipient-uri *or* notify-scheme
       in the subscription creation request.
    3. Make notify-recipient-uri REQUIRED in the mailto and indp
       specs, and notify-scheme REQUIRED in the ippget spec
       (for the subscription creation request).

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



More information about the Ipp mailing list