All,
Here is a short write-up from our IPP phone conference on September 1.
1) Discussion of latest Notification I-D
Internet Printing Protocol/1.1: Event Notification Specification
<draft-ietf-ipp-not-spec-00.doc>
August 25, 1999
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?
RESOLUTION: We cannot decide on this yet. We first need to see worked
out proposals for the candidate delivery mechanisms.
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?
RESOLUTION: This is an implementation rather than standard issue and
is also not limited to notifications. If we want to say anything
about this at all, it should go into the IIG.
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]?
RESOLUTION: Keep it simple, but not simpler than necessary.
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.
RESOLUTION: Proposed solution accepted.
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?
RESOLUTION: We will do an all-or-nothing solution, but report back the
error(s) as exactly as possible (only the wrong attributes or values).
This also triggered some discussion around Per-Job subscriptions.
In the Per-Job case, we will accept the job even if we find errors in
the subscriptions, and also accept valid subscriptions, even if some
subscriptions are invalid. Error reporting should be as detailed as
possible.
ISSUE 6 - Should this appendix be kept in the spec or moved to the
Implementer's Guide?
RESOLUTION: We don't want to make standards texts longer than
necessary. Move to IIG.
2) Optional Operations - Set 2 (rather than Admin Ops)
Harry Lewis had suggested some more rationale text in an email
message. This now needs to be worked into the actual draft and
submitted as an I-D.
3) Implementer's Guide. Henrik Holst from i-data has taken on the
editing for the IPP/1.1 IIG. We will review that in the September
IPP Meeting in Denver.
Please note that the next phone conference will be on September 15th.
Carl-Uno
--
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com