Just a reminder:
I have set up a teleconference for the protocol group:
Monday, April 21, 10-noon PDT (13-15 EDT).
Phone number: 415-357-5792
password: 4145190
I haven't tried to set up an agenda because we didn't adhere to the
one at the last meeting, but I hope that we can discuss two
primary issues:
1) the form-data/HTTP solution
2) the application/IPP solution
Based on discussions at our Memphis and Austin meetings, it is
beginning to seem like the application/IPP is the more fundamental of
the two. I still advocate a MIME structure for the application/IPP
with application/IPPjob and application/IPPprinter objects to hold
attributes for the various operations.
I believe that application/IPPjob and application/IPPprinter objects
consist of a series of lines, each of the form of a MIME header, namely
field = field-name ":" [ field-body ] CRLF
I think that the field-bodies' types should be recognizable from their
syntax. A client can treat all values as text or can recognize their
type. The types are integer, string (quoted), key-word, Boolean,
DateTime (per rfc 822 and 1123), integer with units, set (denoted by
braces and elements separated by commas), range (value separated by .. ).
Most operations should need only a single MIME entity body, i.e.
multipart/mixed won't be necessary much. If CreateJob sends the
application/ IPPjob part, then the SendJob sends Multipart/mixed only if
more than more document needs to be sent. The other place
Multipart/mixed would be used is for the results of GetJobs when more
than one object is returned -- potentially it returns printer
attributes and also job attributes for each job in the queue.
Those of some ideas we can discuss on Monday.
Bob Herriot