Harry,
I agree that there would be a problem if you kept Non-Process-Run-Out and
Space-Curren-Job operations as "private" operations, because as you point
out there is no way to keep vendor's private assignments from colliding.
This is because the operation-id space for privates is allocated in
[ipp-mod] section 4.4.15 as:
0x0013-0x3FFF reserved for future operations
0x4000-0x8FFF reserved for private extensions
However, what the IETF IPP WG is suggesting (from the Raleigh meeting) is
that IBM register the operations using the procedures in IPP/1.0 and IPP/1.1
section 6. Then the specs are kept by IANA (and our PWG server) and the
IETF IPP WG assigns the operation codes in the regular space
(0x0013-0x3FFF), not the private space, so that there is no collision. Also
if some other vendor wants to implement one of these registered operations,
they can, since the spec is public. Its just that these registered
operations wouldn't make it into an RFC and wouldn't be included in an
updated IPP Model and Semantics specification in the future, (though the
assignment of the operation id should be listed in section 4.4.15 with a
pointer to the IANA registry).
Won't that solve your problem?
So you still need to update the version of the spec for those two operations
and submit it for registration following the procedures. It would be good
to do that at the L.A. meeting to get the kinks out of the registration
process.
Comments anyone,
Tom
-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Wednesday, November 17, 1999 07:58
To: hastings at cp10.es.xerox.com
Subject: Registering extended ops
Got your phone msg. Thanks. We agree that registration is a good idea for
the operations that seem peculiar to some folks. We are concerned, however
about the lack of a process for carving out vendor specific namespace to
prevent collisions.
Harry Lewis
IBM Printing Systems