IPP Mail Archive: Re: IPP> NOT - IPPGET Delivery Method - IS

IPP Mail Archive: Re: IPP> NOT - IPPGET Delivery Method - IS

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

From: Michael Sweet (mike@easysw.com)
Date: Thu Oct 25 2001 - 09:41:09 EDT

  • Next message: McDonald, Ira: "RE: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI"

    "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@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@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Thu Oct 25 2001 - 09:44:24 EDT