I have posted the minutes from Seattle at pwg/jmp/minutes/jmp-0897.xxx. The
primary format is PDF. I also exported the file as text but I can't vouch for
the formatting.
I've included a version of the text minutes below:
*************************************************** JMP Seattle Minutes
***********************************
IETF Disclaimer
Although decisions regarding the development of IETF standards are ultimately
wrought via the Internet, face-to-face meetings of interested parties capable
of attending can often accelerate the consensus process. The PWG facilitates
such meetings on a monthly basis for active work groups. These are the minutes
of the PWG meeting of the Job MIB Project which currently pertains directly to
the IETF chartered Job MIB working group.
JMP Meeting
Attending
Attending the Seattle JMP meeting were:
Yasuo Bato - Japan Computer Industry Inc.
Ron Bergman - DataProducts (Chair)
Andy Davidson - Tektronix
Lee Farrell - Canon
Jonathan Fletcher - Intermec
Tom Hastings - Xerox (Editor)
David Kellerman - Northlake Software
Rick Landau - DEC
Harry Lewis - IBM (Secretary)
Paul Moore - Microsoft (Host)
Bob Pentecost - HP
Stuart Rowley - Kyocera Electronics
Yuki Sabahi - Japan Computer Industry Inc.
Bill Wagner - Osicom/DPI
Plans and Schedule
The Seattle JMP meeting opened on 8/8/97 with an overview of the plans and
schedule for the Job MIB standards effort.
1. Job MIB version 0.85 is planned to be released 1 week following this meeting
or on 8/15.
2. There will be 1 week for comments on v0.85 so these are due by 8/22.
3. There will be a Teleconference on 8/26 at 1-3 pacific 4-6 eastern to review
comments.
4. If a final revision is needed, v0.86 will be published on 8/29.
5. There will be a 9/6 deadline for comments on v0.86 - EDITORIAL ONLY.
6. The final draft of the Job MIB will be submitted to the IESG on 9/8.
JMP Major Outstanding ISSUES
Only two major issues remained with the Job MIB as we entered the Seattle
meeting.
These were Nested Attributes (especially jmJobSubmissionID) and Localization
(of agent and host supplies text strings).
1. Nested attributes.
The general rule for nested attributes is that the Job MIB agent will always
use
the most recent value. Client and intermediary software must be aware of this
rule.
As an example, if a Novell P-Server implementation is wrapping a print job
with
another job for putting on a banner page, the P-Server should refrain from also
supplying a jmJobSubmissionID since P-Server has an internal mechanism for
tracking
jobs but the client may wish to use the Job MIB. On the other hand, in an
integrated,
bidi port monitor environment, such as NT, the Job MIB based port monitor will
want
to add jmJobSubmissionID, not the client, since the client will be utilizing NT
print
API's to obtain job information from the port monitor.
Tom will add the following to the Job MIB specification - "The agent always
takes
last attribute for nested situations."
2. Localization.
David Perkins had submitted e-mail comments which resulted in Issues 111 and
112.
Basically, how does a management application determine the coded character set
for
text strings in the Job MIB which have been generated by the agent (111) or
passed
in by the client upon job submission (112).
The two basic proposals discussed were to force UTF-8 for all strings or
provide a
way to "tag" a string as to it's character set.
Issue 111 - It was argued that printers should know the character set of text
strings
originating in the printer whether as part or the Job MIB implementation, the
Printer
or System MIB, a PDL processing message or whatever. (It was, strangely,
argued later
that a Printer controller and NIC could not be expected to coordinate the
issuing of
IPP job ID's such that the IPP ID and jmJobIndex would be identical... so it is
clear
we have varying perspectives among JMP members about the overall scope of the
Job MIB
agent within the printer.). Printers are very likely to have used 7-bit ASCII
or
Shift-JIS for their internal strings. Printers could implement UTF-8 as the
internal
character set in the future.
UTF-8 presents some interesting challenges when it comes to fitting longer
strings
into shorter attributes - for example if there should be a mismatch between IPP
and
JMP and the Job MIB agent is required to truncate a job attribute text string.
With
UTF-8, characters may be 1 to 6 bytes, so there is no certain truncation
boundary.
For the agent assigned strings (Physical Device Name, Processing Message,
JobSetName),
issue 111 was settled by agreeing to force UTF-8 but assume 7-bit ASCII (or
just
don't implement the objects) if the agent really can't determine the character
set.
Implementations for the Asian markets would use UTF-8 but would default to
Shift-JIS
as a fallback rather than 7-bit ASCII.
ISSUE 112 - There are 19 text strings passed in with the Job MIB. Job Owner is
the
only object. All others are (optional) attributes. Printers cannot be expected
to
transform strings which have been passed in on submission - even though the
simplest
transform, from 8 bit ASCII, would be relatively easy. Printers certainly
should not
be burdened with Shift-JIS to UTF-8 translation.
It was noted that, if the agent simply "echoes" the text string which was
passed in
then it should be possible for management and client applications to enforce
the
"UTF-8" only rule by always passing in UTF-8 and, thus, always expecting it
from
the Job MIB. This is the preferred solution to localization of Job MIB text
strings
originating form the host.
Still, it was argued that an attribute should be added which is the enum of
character
set for the host originated job attributes. This character set attribute would
also
be passed in on submission on a per job (NOT per attribute) basis. If the
character
set in unknown then the value of the character set attribute should be
"unknown" or
just leave attribute off. Default behavior is environment specific and
generally not
specified but the following are the best environment localized guesses