IFX Mail Archive: IFX> RE: IPP> NOT - IPPGET Delivery Met

IFX Mail Archive: IFX> RE: IPP> NOT - IPPGET Delivery Met

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

From: McDonald, Ira (IMcDonald@crt.xerox.com)
Date: Thu Oct 25 2001 - 12:12:38 EDT

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

    Hi Michael,

    Comments below, preceded by '<ira>'.

    Cheers,
    - Ira

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Thursday, October 25, 2001 9:41 AM
    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:
    >
    > 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? :)

    <ira>
    No - the empty string says there is NOT a destination for Printer
    pushed notifications.
    </ira>

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

    <ira>
    Some sort of weak UID-like URI would be fine for uniqueness.
    But - we defined 'notify-recipient-uri' to be the destination
    for notifications. Any form of UID-like URI (yours is sensibly
    based on the server and not the client system ID) fails that
    definition. And we said that the Printer MUST validate
    'notify-recipient-uri'. But Printer implementations are
    NOT validating 'ippget:' URI so far, because there's no
    good reason to bother. A URL scheme MUST define unique
    identifiers (at least within a Resolver's scope).

    The fix possibilities I can think of are:

    (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".

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

    </ira>

    -- 
    ______________________________________________________________________
    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 - 12:12:47 EDT