I agree that we should take the time to consider XML, and I also agree
with the other commenters that we need to do this expediously.
One (of many) concerns that need to be discussed about using XML
is the increased size of actual printing devices that support IPP.
HTTP implementations are down to 20-30 K of code so using HTTP was not
seen as an undue burden. What is the increased size to support an XML
interpreter?
One of the advantages of our binary IPP encoding is that it was light
weight enough that volume desktop printers could implement it (and
implementations are under way by a number of vendors). Therefore, the
same IPP protocol (with the binary encoding) is a job submission protocol
that can be used between clients and servers, between clients and
spooling devices, and between servers and non-spooling devices. This is a
great improvement over DPA where DPA has only been implemented
by clients and servers; no non-spooling devices are supporting DPA.
It also greatly simplifies server implementations when the protocol they
receive is the same as they send, so that a server can just forward
jobs to devices after spooling, rather than having to perform complex
job submission protocol mappings.
It would be a shame if IPP became too expensive to implement in non-spooling
devices.
Tom
At 10:21 01/09/1998 PST, Paul Moore wrote:
>This is a formal request that we delay the finalization of the IPP spec
>until we have looked at the possibility of using XML as the protocol format.
>>I know this is revisiting an old issue but we need to make sure we do the
>right thing. When the current format was proposed there was no good method
>for representing structured data in an ASCII data stream. XML is now
>available and seem to be the coming wave. I also know that most of the new
>standards that will come out over the next year will be based around XML
>(and protocol specific HTTP commands). By ensuring that we are in the centre
>of these standards we will be able to leverage many common tools that will
>emerge to support and manage these protocols.
>>There will definitely be down-sides so we need to debate this issue - not
>least the investment that some of us have already made in building using the
>current spec.
>>I think that somebody from MS will be in Hawaii.
>>Paul Moore
>>