I have a few comments for our MOD conference tomorrow:
1) Scope
We start having a considerable amount of detail about Semantics, but the
Model part is still fairly thin. I had expected to see a little more about
the total IPP environment under Model e.g. containing some descriptions on
how IPP relates to other services that it will use such as Directory and
Security (the SEC group will try to contribute some material on the latter).
I also think that the Model part should explain some of our design
principles, such as "best effort", "late binding" of parameters etc. We
have had extensive discussions on these subjects, but I feel that they are
not yet properly reflected in the right places in the document.
Are still talking about HTTP in a couple of places (we did in 1.2). These
need to be replaced with some transport independent formulations.
2) There seem to be a number of attributes that were discussed as scenario
or directory attributes, which I cannot find in the Model document. Were
they just ignored by the Model subgroup? What happened to I18N?
3) Several of the attribute semantics in 5.4.3 seem to indicate that there
is only one document per job. This needs to be fixed. We need to describe
the text so it is obvious that one document can be included, and another
one referenced in the same job, which I assume we still want to allow?
4) I still think that we should talk about documents as objects (even if we
do not have any operations on them in ths version). DPA waffled about
objects - do we really want to produce yet another standard that is only
quasi-object-oriented?
5) The number and granularity of the operations still needs discussion. My
suggestion is to split up the Print operation into several steps (at leat
separating the attributes from the actual document data into two
operations. Roger might have suggested even more of a split. You can more
easily combine operations when you map them to transport, but you cannot
start splitting them up (or you will violate the Model). Any comments about
HTTP efficiency seem totally irrelevant, what is relevant is that several
operations over e-mail might be akward, but they could be packaged together
in a MIME type to solve that problem :->
6) Don't forget the cross-check against RFC 1179.
All in all, I do not think we are quite as far on this document as some
tend to think.
See you on the phone tomorrow.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com