"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? :)
> 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...)
-- ______________________________________________________________________ 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 - 09:44:24 EDT