Thanks for your comments. I hope it is ok to forward them and my
replies to the IPP mailing list.
Tom
At 10:40 03/25/97 PST, Bob Sproull - Sun Microsystems Labs BOS wrote:
>A couple of additional thoughts on the IPP draft:
>
>1. I'm not entirely sure how locales are handled. My preferred approach
>would be to let the client specify the locale (Java does this using
>the two-character ISO country code + the two-character ISO language code),
>and ask the printer to return its messages (or a certain set of them)
>using this locale. This puts the onus for correct interpretations
>on the printer rather than on the client. (In section 6.2.2.4, this
>seems to be something the printer sets rather than the client.)
I tend to agree with you. The user-locale attribute is set by the
Printer, but page 58, section 5.3.2.3, says that the Printer gets the
"most authentic value it can obtain from the protocol over which the [Print]
operation was received from the client."
So the assumption is that the protocol conveys the locale that the user
is in to the Printer in the Print operation. So we would have to look at
the Protocol standard (a separate document) to make sure that it passes
the locale of the user. If the protocol does pass the user's locale to the
Printer, and then the Printer sets the value of the job's user-locale
attribut with this value, then we are meeting your objective.
Perhaps we need to clarify this description more.
>
>2. I strongly recommend *not* including in IPP a complete set of printer
>management facilities. I think this should be a totally separate standard
>(named IPMP or something). The reasons are:
> 1. The protocols probably want to evolve independently, with
> separate version numbers. It is likely that IPP will
> want to evolve more slowly than IPMP, because implementations
> will have to be spread more widely. Moreover, I think
> the IPMP stuff is likely to be more complex than the
> printer client stuff.
> 2. IPMP has to interrelate to a whole different set of issues,
> e.g., compatible with the Printer MIB stuff, perhaps with
> other network- and system-management APIs and protocols.
> 3. Most important, I think the widespread deployment of these
> protocols should be handled separately. Keeping IPP simple
> and getting it done promptly will be essential if it is
> to succeed.
I think that the entire IPP group is in agreement here. We keep talking
about IPP V2.0 for management facilities, so IPP V1.0 will NOT have
any management facilities. Do you see any operations in what we have so
far that make you think that we are including management facilities in
IPP V1.0?
>
>Bob
>
>
>