I have a few comments about Tom's latest document. I have talked with Tom and
we have general agreement about the suggestions below. I agreed to write them up
and send them out to the mailing list.
1) I am still bothered by specifying the syntax of text and name according
to RFC 2184, ( charset "'" language "'"). I don't like the idea of
text and names having a "syntax". Also, the restriction of text and
name values to those charsets that has ASCII as a subset bothers me
-- especially as new systems move toward UCS-2 as the native
representation.
I propose a different solution:
a) separate the charset/language information from the text/name value and put
them into separate values, like a multivalued attribute.
b) For the vast majority of cases where the charset and language of the text/name
attribute is the same as at the operation level, the charset/language value is
not needed. So the attribute stays as a single valued attribute, as it was in
the July draft.
c) For those rare cases where the language or charset of an attribute differs from
language and charset specified at the operation level, treat the attribute
as a pair of values where the first value has a new type "charset/language"
and the second has a type of 'name' or 'text'. The first value is in US-ASCII
and has the syntax of RFC 2184, e.g. "iso-latin-1'de'", and the second value is
the text/name in the language and charset specified in the first value
with no restriction on the charset for the text/name value. If
either the language or charset field is empty, the value at the
operation level is inherited.
Note: if we had dictionaries, I would instead propose that text/name values
with an overridden charset or language could be a dictionary containing the
language and charset overrides along with the text/name value. But we don't
have dictionaries yet.
Note: alternatively, we could also add a special array type consisting of
n triplets type/value-length/value where there would be three values:
charset (type "charset", language (type "language") and a text/name value.
d) This change makes the syntax of all requests and most responses be the same
as it was before we added the two quotes syntax to text and names.
2) Why isn't content-charset an optional attribute for the client to send?
a) I would prefer that the default for a request and response to be UTF-8
if no content-charset parameter is present.
b) Then there is no need for a printer to have a default-content-charset.
c) make it a group 1 operation attribute and not an HTTP header. Thus
rename it 'attributes-charset'
3) Why isn't content-natural language an optional attribute for the client to send?
a) I would prefer that the default for a request and response to be the
server's default natural language.
b) Then there is still a need for a printer to have a default-natural-language.
c) make it a group 1 operation attribute and not an HTTP header. Thus
rename it 'attributes-natural-language'
4) If my proposal is accepted, then jobs for most printers are unchanged from the
July draft by this proposal. They have no operation attributes
specifying charset or language and the text/name attributes contain
their value only and have no information about charset and
language. The default charset UTF-8 and the printer's default
language are used for all requests and responses. But the mechanism
is there for full support of charsets and languages if needed.