ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-notify-proposal.pdf
The .pdf version should be used to make comments using the line numbers.
Of coures other issues are welcome as well, via e-mail or during the telecon.
Tom
The line numbers refer to the .pdf version:
1. Line 89-91:
ISSUE a: Should we keep the ability for the System Administrator to define
default notification, if the client does not supply any?
2. Line 130-136:
ISSUE b: Are we making the recipients job more difficult on a problem
notification by sending the job-id of the job that had the problem, rather
than the job-id of the job the requested the notification?
3. Line 130-136:
ISSUE c: Is there a security problem with sending the job-id of a job that
does not belong to the user that submitted the job to the designated
notificatio recipient? We already allow the security policy to prevent a
user from seeing any other jobs.
4. Line 210:
ISSUE 1: Ok to have combined these two events into one event (and one
event group) for simplicity and specified that the notification content is
the same for all notification recipients receiving this event?
5. Line 223:
ISSUE 2: Should we register a "job-deadline-to-start" Job Template
attribute for use with IPP/1.0?
6. Lines 241-265:
ISSUE d: What notification schemes do we want to include in our standards
track
notificaition RFC? Any that have not been approved should probably be in a
separate document, in case they get held up with URL scheme registration
bottlenecks.
7. Lines 241-265:
ISSUE e: What notification schemes do we want to progress in parallel with
this notification proposal?
8. Line 247:
ISSUE f: For the 'tcp-ip-sockets' notifiation scheme, too many other IETF
groups might like to get involved, slowing us down, even though the method
is only appropriate for IPP. Perhaps we should change the name to represent
a more limited scope, like 'ipp-tcp-ip-sockets'? Same for the snmpv1,
snmpv2, and snmpv3 schemes.
8. Lines 241-265:
ISSUE g: The representation for the notificatio content needs to be specified
for each method. All should use the multipart/alernative, except for the
three SNMP methods.
9. Lines 353-378:
ISSUE h: Need to clarify that the validation is independent of the value of
ipp-attribute-fidelity, like all Operation attributes, and unsupported
values are ignored, rather than rejecting the request.
10. Line 404 and Table 1:
ISSUE 3: Do we need/want to add the missing attributes to IPP as Printer
object attributes that are indicated as "-" in the IPP attribute column
to align with the Job Monitoring MIB?
11. Line 433:
ISSUE 4 - Should we change the name that is reserved in the IPP/1.0:
Protocol Specification from 'dictionary' to 'collection' before the RFC is
published?