Hi,
It seems that Ned is not subscribed to the IPP DL so his recent messages
have bounced.
Here the input we got from Ned for the recent IETF meeting.
Carl-Uno
Carl-Uno Manros
10701 S Eastern Ave #1117
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-310-251-7103
Email carl at manros.com
-----Original Message-----
From: ned.freed at mrochek.com [mailto:ned.freed at mrochek.com]
Sent: Wednesday, March 20, 2002 7:35 AM
To: ipp at pwg.org; carlmanros at hotmail.com
Cc: Carl; ned.freed at mrochek.com; paf at cisco.com
Subject: IESG/AD reviews of IPP notifications documents
General comments: (IESG review)
The IESG is concerned that there appear to be three distinct notification
mechanisms for IPP, none of which are mandatory to implement. The result
does
not appear to guarantee sufficient interoperability. The fact that
notifications are optional in IPP doesn't eliminate the need for
notifications,
if implemented, to interoperate.
The obvious way to address this, of course, is to have one or more mandatory
to
implement mechanisms. And while the IESG is aware that the working group
previously could not settle on a single mechanism, the IESG notes that
mandatory to implement does not imply mandatory to use.
draft-ietf-ipp-indp-method-06.txt (IESG review)
All of the Security Mechanisms articulated are MAY, so it appears to be
possible to build an implementation without any security mechanism and still
be
conformant. The IESG doesn't believe this is what we should be doing. There
should be at least one mandatory security mechanism.
There seems to be some potential that indp requests could be directed
at a third party that is not prepared to receive them. Some discussion of
this issue in the security considerations section would be useful.
draft-ietf-ipp-notify-mailto-03.txt (AD review)
It would be nice if this document refered to RFC 2821 and RFC 2822 rather
than RFC 821 and RFC 822.
Section 3, third paragraph. I can readily understand how a printer could
apply
S/MIME to a notification (although I'm not sure where it would get the
necessary key or keys). However, I fail to see how delivery status
notification
requests (RFC 1891) could be used. If a DSN is requested where would the
resulting message be sent? How would the printer react to it? I guess a
secondary notification mechanism could be used in the event of a delivery
failure, but in order for that to work the printer would have to have an
SMTP
server. Repeating a notification in the event of failure doesn't seem like a
good idea in any case.
In addition to the specific header field requirements in section 6, it might
be
good to note that conformance to RFC 822/2822 formats is required. And given
that the specific field values recommended will necessarily involve 8bit
characters in multiple charsets, a statement saying that encoded words as
defined in RFC 2047 must be used is essential.
This document currently does not discuss support for SASL authentication
in the context of SMTP. This is probably something that should be added,
especially since it probably requires additional printer configuration
capabilities.
This entry in the bibliography is messed up:
[RFC2046]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999.
The bibliographic entry [ipp-req] is referenced but never defined.
draft-ietf-ipp-notify-get-06.txt (AD review)
This document is good to be last called once the general notification issues
raised above are addressed.