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