ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990825.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990825.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990825-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990825-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-990825.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-spec-00.txt
Please read and send comments to the DL before the next meeting in Denver,
September 22-23 1999.
I also made a separate change history which covers the last 12 months of
changes as an Internet-Draft:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-change-history-990822.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-change-history-990822.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-change-history-990822.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-change-history-00.t
xt
Carl-Uno will submit each of these to the Internet-Draft secretariat.
Send comments to the IPP DL. There are only six (minor) issues left (not
counting the delivery method documents which are going to be separate:
ISSUE 1: Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability. Which one or
ones should be REQUIRED?
ISSUE 2 - What is the value of the "subscriber-user-name" when the
Subscriber is a server send a job to an IPP Printer? The original Job
Submitting End User use name or some "user name" that identifies the Server?
ISSUE 3 - Are these abbreviated operation definitions ok for
understandability and conformance, or should we use the more verbose
definition style of the [ipp-mod]?
ISSUE 4 - The client-error-uri-scheme-not-supported is already an IPP/1.1
status code and section 3.1.6.1 indicates that the "document-uri" attribute
NEED NOT be returned in the Unsupported Attributes group, otherwise, we
could use that error code and REQUIRE that offending "xxx-uri" attribute(s)
to be returned.
ISSUE 5 - Should the entire "job-notify" operation attribute be ignored, if
one of its member attributes has a problem, or should just that member
attribute be ignored? If the latter, then is just the member attribute
returned in the Unsupported Attributes group?
ISSUE 6 - Should appendix A showing all the attributes be kept in the spec
or moved to the Implementer's Guide?
Thanks,
Tom