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

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

Michael Sweet mike at easysw.com
Thu Oct 25 09:41:09 EDT 2001


"McDonald, Ira" wrote:
> 
> Hi Michael,
> 
> Wait - the IETF _will not_ allow 'ippget:' (with nothing following or
> with nonsense that isn't a protocol target address following) as a
> URL scheme.  It violates all the rules of URLs usage.

Doesn't the empty string do that, too? :)

> The idea is that the EMPTY string (not the 'ippget' value) is
> unambiguous.  BECAUSE it's empty there is NOT a protocol target for
> the IPP Printer object to send notifications to.  The IPP client
> must retrieve the notifications in-band via IPP.
> ...

As long as the IETF will go along, I'm game.  I'm just having
Seinfeld flashbacks (the spec about nothing? :) and am not 100%
sure that I agree that an empty URI should be enough to indicate
the notification method being used.  It isn't a "clean"
implementation (IPPGET becomes more of a special case) and precludes
the implementation of future notification schemes that might need
similar treatment (like a "broadcast" notification scheme...)

If the IETF doesn't like just the scheme name, would a pseudo-URI
like:

    ippget://server/subscription-id

do the trick?  This would identify the subscription and server
to any potential user agents - that is where the notifications
will be found (kindof like "check mailto:user at server for the
notifications") - while at the same time providing a URI syntax
that the IETF can live with...

Thoughts?

(I say "pseudo" URI because the IPP server really won't use it,
 it would only be for the consumption of others...)

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



More information about the Ipp mailing list