[From nobody Wed May  6 13:54:24 2009
X-Sieve: cmu-sieve 1.3
Return-Path: <rbergma@hitachi-hkis.com>
Received: from cog-codev.dpc.com (cog-codev.dpc.com [192.168.2.1])
	by skate.dpc.com (8.8.8+Sun/8.8.7) with ESMTP id IAA03915
	for <rbergma@skate.dpc.com>; Tue, 4 Jan 2000 08:48:33 -0800 (PST)
Received: by cog-codev.dpc.com; id PAA10682;
	Sat, 9 Feb 2036 15:17:29 -0800 (PST)
Received: from newmai.dpc.com(10.50.0.101) by cog.dpc.com via smap (V5.0)
	id xma010680; Sat, 9 Feb 36 15:16:29 -0800
Received: from cog-codev.dpc.com (firewall-user@cog-dpceng.dpc.com
	[10.30.0.182]) by newmai.dpc.com (8.9.3/8.9.3) with ESMTP id IAA28096
	for <rbergma@hitachi-hkis.com>; Tue, 4 Jan 2000 08:48:07 -0800 (PST)
Received: by cog-codev.dpc.com; id PAA10673;
	Sat, 9 Feb 2036 15:16:28 -0800 (PST)
Received: from skate.dpc.com(192.168.2.252) by cog.dpc.com via smap (V5.0)
	id xma010670; Sat, 9 Feb 36 15:15:47 -0800
Received: from hitachi-hkis.com (bud.dpc.com [192.168.2.47])
	by skate.dpc.com (8.8.8+Sun/8.8.7) with ESMTP id IAA03809;
	Tue, 4 Jan 2000 08:46:51 -0800 (PST)
Message-ID: <387226B3.BF0FC8B3@hitachi-hkis.com>
Date: Tue, 04 Jan 2000 08:58:28 -0800
From: Ron Bergman <rbergma@hitachi-hkis.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ifx@pwg.org
Subject: Comments on the QUALDOCS Protocol Specification
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,

This is an excellent start on the QUALDOCS Specification!

I have several comments, most of which are nits.

1. I am not sure why the current IPP notifications work has
   been dismissed (section 5.3).  This effort has made
   significant progress in the last several meetings and
   would provided significant functionality that is needed
   by QUALDOCS.

2. What is the IPP job sheet system that is referred to in
   section 5.4, first paragraph ?

3. The keyword 'job-description' identifies an attribute
   group.  How is this intended to be used in section 5.4 ?

4. Section 5.5, Identity Stamping.  If I recall correctly,
   this subject has been discussed in several previous
   meetings with Richard Shockey.  The conclusion has been
   that identify stamping is provided by the sender within
   the document and is transparent to the receiver.

5. In section 7.4, I believe I understand what you mean by
   "no 'native' IPP features".  But this should be
   clarified.

6. Section 8 "document transmission systems" needs to be
   defined.

7. Since vCard is a unique format, I suggest that the data
   type for QD-sending-user-identity and for
   QD-receiving-user-identity be unique.  A new data type
   "vcard" could be defined.

8. The data type for QD-TIFF-capabilities could also be new
   type.  (Not as obvious as vCard.)

Now the NITS:

1. Current practice for naming attributes uses all lower
   case characters.  Is there a reason for your use of
   mixed lower/upper case ?

2. The paragraphs that introduce the new attributes describe
   them as "job attribute" or "printer attribute".
   Although section9 is more explicit, it would be better if
   these paragraphs stated "job description attribute", or
   "job template attributes", or "printer description
   attribute" as appropriate.

3. The names of IPP operations should be in title case.  For
   example, in section 6.1 "cancel-job" should be shown as
   "Cancel-Job".  "Get-Jobs" and "Get-Job-Attributes" are
   also shown incorrect.

4. Section 8.1 defines "QD-destination-schemes-supported".
   Section 9.5 defines "QD-destination-scheme-supported".


    Ron Bergman
    Hitachi Koki Imaging Solutions


]