In the rules for processing subscription Template Attributes, Section
5.2, Rule 8 d, the Status code 'client-error-too-many-subscriptions'
indicates that the client SHOULD try again later when a subscription
object could not be created because the printer is out of space
for subscription objects. For the per-job subscription, this seems
too strong a recommendation, given that the job may complete
while the client waits to resubscribe. Is there another reason this
is not a MAY?
In notify-recipient-uri (Section 5.3.1, page 23), there is a
requirement that
the printer MUST treat the address part of the attribute as opaque.
This doesn't
make sense to me. One of the real security issues here is that the
system
doesn't have any mechanism to prevent abuse of the third party
notifications. If you allow the printer to optionally parse the
address,
you could at least have simple rules like "all notifications must be
within example.com". I don't see any reason to disallow that
by forcing the printers to treat them as opaque. They MAY treat
them as opaque, of course.
5.3.3.5.3 on special cases for matching rules says that a printer MUST
NOT try to consolidate seemingly identical even notifications and MUST
NOT reject subscription creation operations that would create this
scenario.
Splitting the examples so that they handled this case separately
would help, as the current text mixes the allowed case (delivering a
notification for only the more specific state when two are subscribed)
with this case in confusing ways.
8.2 says that the message in notify-text is in text/plain with the
charset
specified in the "notify-charset" attribute. This section should
explain
how to avoid conflict if text/plain has a charset parameter that does
not
match the notify-charset attribute. Disallowing a charset parameter
would
work, but it needs to be specified.
The structure of the appendices is pretty strange for an RFC, given
that Appendices A-F occur in what we would consider the body
of the RFC, and G and H after. I'd suggest that the appendices prior
to the Authors' addresses be given normal section identifiers,
especially
since they are interleaved with standard text. Also, do we
commonly have normative appendices (see Appendix D, for example)?
The IANA registration section 24.2 indicates an Enum attribute value
registration. This is actually in the ipp-registrations IANA registry,
and
though the cited RFC 2911 makes that clear, it might be useful
to say "additional ENUM Attribute Value Registrations within the IPP
registry"
to avoid confusion.
The document lists the Copyright statement as an appendix (appendix H)
and gives its status as Informative. I think it would be better to use
the
common form and leave the question of whether it is normative or
informative to the lawyers.