IPP> NOT - Updated IPP Notification spec and Change History documents

IPP> NOT - Updated IPP Notification spec and Change History documents

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Aug 26 07:05:03 EDT 1999


I've updated the Notification spec with the agreements from the 8/18/99 and
8/19/99 IPP WG meeting:

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







More information about the Ipp mailing list