I'm not very sympathetic to this "12th hour" request for an XML rewrite
of the IPP Protocol spec...I'd like to comment on some hidden effects of
Paul Moore's request.
At present the IPP message ('application/ipp') is free-standing - while
a few attributes are mapped into HTTP/1.1 header fields, one is allowed
(by the IPP Model) to wrap all IPP attributes (including "operation-id")
in the IPP message. So 'application/ipp' can be moved equally well via
interactive (HTTP/1.1) or store-and-forward (SMTP) protocols.
Josh and Paul are opposed to using HTTP Post to convey IPP messages, but
their rationale is faulty. While firewalls shouldn't have to examine
the content of every incoming HTTP message, they now routinely examine
various HTTP header fields (for security and other site-policy reasons),
and 'Content-Type' of 'application/ipp' couldn't be plainer!
Adding new HTTP verbs for IPP will just make mappings of IPP to other
protocols harder in the future, which works against ubiquity.
My two cents,
- Ira McDonald (High North, outside consultant at Xerox)