JMP Mail Archive: Re: JMP> Editorial Comments on Job MIB Version 0.85

Re: JMP> Editorial Comments on Job MIB Version 0.85

Tom Hastings (hastings@cp10.es.xerox.com)
Tue, 9 Sep 1997 17:26:02 PDT

At 09:03 09/09/97 PDT, Ron Bergman wrote:
>Tom,
>
>Very good! Most are closed. I only have a the following additional
>comments.
>
>
> Ron
>
>
>On Fri, 5 Sep 1997, Tom Hastings wrote:
>
>> Ron,
>>
>> Good suggestions.
>>
>> Thanks,
>> Tom
>>
>> At 09:34 09/03/97 PDT, Ron Bergman wrote:
>> >Tom,
>> >
>
>...snip...snip...
>
>
>>
>> >3. New text on page 26, second paragrpah:
>> >
>> > NOTE - For a number of job submission protocols the server/device
>> > assigns an integer job identifier when accepting a job so that the
>> > submitting client can reference the job in subsequent protocol
>> > operations (For example, see IPP [ipp]). For such implementations, it
>> > is recommended that the value of the job identifier and the value of
>> > jmJobIndex be the same, so that
>> >
>> > First, this text is very similar to what is on page 20. Second, the
>> > last sentence is incomplete.
>>
>> So how about changing it to refer back to page 20:
>>
>> NOTE - For a number of job submission protocols the server/device
>> assigns an integer job identifier when accepting a job so that the
>> submitting client can reference the job in subsequent protocol
>> operations (For example, see IPP [ipp]). For such implementations, it
>> is recommended that the value of the job identifier and the value of
>> jmJobIndex be the same (see section 3.2).
>>
>In reading both sections again, I do not see a need for any additional
>text here at all. The end of the previous paragraph reads:
>
> "See section 3.2, entitled 'The Job Tables and the Oldest Active and
> Newest Active Indexes' for the specification of how the agent shall
> assign the jmJobIndex values."
>
>This text should be sufficient for the reference to this section. The
>exisiting paragraph, or your revised version, is already covered in
>section 3.2.

I agree. Even shorter.

>>
>> >4. Revision to paragraph 3.5.1, page 26. The current text is clumsy.
>> >
>> > 3.5.1 Text generated by the server or device
>> >
>> > There are a few objects and attributes generated by the server or device
>> > that shall be represented using the Universal Multiple-Octet Coded
>> > Character Set (UCS) [ISO-10646]. These objects and attributes are always
>> > supplied (if implemented) by the agent, not by the job submitting client:
>> > 1. jmGeneralJobSetName object
>> > 2. processingMessage(6) attribute
>> > 3. physicalDevice(32) (name value) attribute
>> >
>> > The coded character set for representing these objects and attributes
>> > SHALL be UTF-8 as recommended by RFC 2130 [RFC 2130] and the "IETF
>> > Policy on Character Sets and Language" [char-set policy]. The
>> > 'JmUTF8StringTC' textual convention shall be used to indicate UTF-8 text
>> > strings.
>> >
>> > NOTE - For strings in 7-bit US-ASCII, there is no impact since the UTF-8
>> > representation of 7-bit ASCII is identical to the US-ASCII [US-ASCII]
>> > encoding.
>>
>> Much better. The only suggestion I have would be to change the SHALL
>> in the second to last sentence to is, since the 'JmUTF8StringTC' textual
>> convention is UTF-8. So the sentence is just explaining what JmUTF8StringTC
>> is. The preceding sentence has the SHALL in it.
>>
>> So the sentence would become:
>>
>> The 'JmUTF8StringTC' textual convention is used to indicate UTF-8 text
>> strings.
>>
>Yes, good change.
>>
>> >5. Change title of paragraph 3.5.2, page 26.
>> >
>> > 3.5.2 Text generated by the job submitter
>>
>> Better.
>>
>>
>> >6. Page 32, JmUTF8StringTC. The following text is repeated from paragraph
>> > 3.5.1, which is also referenced here. This should be deleted.
>> >
>> > NOTE - The values of objects and attributes using this textual
>> > convention are generated by the server or the device, not by the
>> > job submitter.
>>
>> I agree.
>>
>>
>> >7. Page 32-33, JmJobStringTC. The following text is repeated from paragraph
>> > 3.5.2.
>> >
>> > "To facilitate internationalization, this TC represents
>> > information using any coded character set registered by IANA
>> > that has the following properties: (1) code positions from 0 to
>> > 31 SHALL not be used, (2) 32 to 127 SHALL be US-ASCII [US-
>> > ASCII], (3) 127 SHALL be unused, and (4) the remaining code
>> > positions 128 to 255 SHALL represent single-byte or multi-byte
>> > graphic characters structured according to ISO 2022 [ISO 2022]
>> > or SHALL be unused. While it is recommended that the coded
>> > character set be UTF-8 [UTF-8], the actual coded character set
>> > SHALL be indicated by the value of the jobCodedCharSet(7)
>> > attribute for the job.
>> >
>> > NOTE - The values of objects and attributes using this textual
>> > convention are either generated by the job submitter or
>> > defaulted by the server or device when the job submitter does
>> > not supply values."
>> >
>> > Change to:
>> >
>> > "To facilitate internationalization, this TC represents
>> > information using any coded character set registered by IANA
>> > as specified in paragraph 3.5.2. While it is recommended that
>> > the coded character set be UTF-8 [UTF-8], the actual coded
>> > character set SHALL be indicated by the value of the
>> > jobCodedCharSet(7) attribute for the job."
>>
>> Good shortening.
>>
>> >10. Page 1, second paragraph. (Closing quote is in the wrong position.)
>> >
>> > as reference material or to cite them other than as "work in
>> > progress."
>> >
>> > Should be:
>> >
>> > as reference material or to cite them other than as "work in
>> > progress".
>>
>>
>> This is the only one I disagree with! Proper English is that the
>> quote comes last. Look in any book. Also this is just copied from
>> the usual IETF template (which is also correct).
>>
>We can leave as it is, since this will not appear in the final document it
>is not an issue. (I did check an number of drafts and both forms were
>used.
>
>
>
> Ron Bergman
> Dataproducts Corp.
>
>
>
>