I entirely agree with Scott. Supporting a service for which no
real support is provided doesn't jive with traditional approaches
(ie, just don't answer the call if you're not supposed to talk).
Was there some underlying goal/idea not stated in the minutes
for which this approach is necessary?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Scott Lawrence wrote:
>> The agreement Roger describes sounds good; one minor nit...
>> RKD> 9) If a client somehow derives a URI and tries to connect and the
> RKD> service (e.g. Printer-URI) has been turned-off, an appropriate
> RKD> http error code will be returned.
>> Why impose that requirement? That would mean that a printer without
> security (for whatever reason) would need to listen on the TLS port
> and implement enough of the handshake to negotiate no security so
> that it can send an HTTP error. Similarly, a secure-only server
> would need to listen on the unsecured port just to send an HTTP
> error. Just let TCP do the right thing - if they've constructed an
> invalid URI (one with the wrong scheme or port number in it), then
> it won't work, which is what should happen. It really isn't the
> business of the IPP spec to say what will happen on a TCP port on
> which IPP is not available.
>> --
> Scott Lawrence EmWeb Embedded Server <lawrence at agranat.com>
> Agranat Systems, Inc. Engineering http://www.agranat.com/