IPP> MOD - Updated Model sections for internationalization

IPP> MOD - Updated Model sections for internationalization

IPP> MOD - Updated Model sections for internationalization

Robert Herriot Robert.Herriot at Eng.Sun.COM
Mon Oct 13 19:03:18 EDT 1997


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.






   



More information about the Ipp mailing list