General comments:
1. Given that we have an embedded protocol as Roger has outlined in
the "whyhttp" doc on the server, Bob suggests that we should use
POST for all IPP operations. I am now also convinced this this is the
case.
2. We should introduce the fields for Content-length and Document-length
fields. Bob notes that "these fields are nice in some circumstances, but
they create a problem of receiving documents via stdin where the length
is unknown." If the value is "bounded" then look the the "boundry="
fields. I think that it is up to the implmenter of entity to decide on the
tradeoff between "use an aglorithm that generates a unique string with a
low probability of conflict" and "use an algorithm that generates a unique
string with ZERO probability of conflict (prescan, filter and modify as the
stream is passed, etc.)" The rules should be: If the length is known use
it. Otherwise use a "low probability" boundy algorithm unless some
environment QOS indicator suggests using a "zero probability" boundry
algorithm.
3. The embedded protocol that Roger suggests is a GREAT idea since it
can then be sent in an HTTP POST, and email, or anything else. The IPP
protocol is separated from the transport. This lack of clean separation
has caused MANY problems in migration to new products and
technologies.
4. I agree with Bob's suggestions on MIME encodings or documents and
jobs with regard to order and scoping.
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************