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 12:12:38 EDT 2001


Hi Michael,

Comments below, preceded by '<ira>'.

Cheers,
- Ira

-----Original Message-----
From: Michael Sweet [mailto:mike at 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 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...)

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



More information about the Ipp mailing list