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.
>> >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.