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: McDonald, Ira (IMcDonald@crt.xerox.com)
Date: Thu Oct 25 2001 - 12:12:38 EDT

  • Next message: Michael Sweet: "Re: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI"

    Hi Michael,

    Comments below, preceded by '<ira>'.

    - 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? :)

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

    > 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


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


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

    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.


    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:14:02 EDT