Comments below, preceded by '<ira>'.
From: Michael Sweet [mailto:email@example.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
> 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 firstname.lastname@example.org Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Thu Oct 25 2001 - 12:14:02 EDT