FW: IFX> Telecon - Fri 14 Dec IPPFAX Protocol review, 9-11AM PDT (12-2 EDT)

Hi,

With apologies for late notice.  The revised IPPFAX protocol
spec is being reviewed this Friday (14 December 2001) in a
telecon of the PWG IPPFAX WG.  We're trying very hard to
finish this spec up before the end of December, so that
implementations can proceed in January (some are now in
progress) and we can have an interoperability test in
spring (?) 2002.

The announcement of the document with URLs for MS Word and
Adobe PDF versions is below.

Please join us if you are interested.

Cheers,
- Ira McDonald, for the PWG IPPFAX WG
  High North Inc


-----Original Message-----
From: Hastings, Tom N [mailto:[email protected]]
Sent: Monday, December 10, 2001 12:07 PM
To: IPP FAX DL (E-mail)
Subject: IFX> Telecon: IPPFAX Protocol review, Fri, Dec 14, 9-11AM PDT
(12-2 ED T)


The canceled November 9 meeting to review the updated IPPFAX Protocol spec
will be held:

Friday, December 14, 9-11 AM PDT (12-2 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970

I'll post the updated IPPFAX Protocol spec (version 08) later today or first
thing tomorrow and I'll list the few remaining issues then in the email
announcement.

Thanks,
Tom

---------------------------

I've down loaded the IPPFAX protocol spec version 0.8 for the Friday
December 14 telecon.  This version has the agreements reached at the IPPFAX
WG meeting in San Antonio, October 24.  See the minutes.  The version
without revisions is 56 pages (one longer than the previous version).  The
files are:

ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08-rev.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08-rev.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08.doc

The telecon details are:

Friday, December 14, 9-11 AM PDT (12-2 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970

The agenda for the telecon will be:

1. The 5 issues embedded in the document (excerpted below).  

2. Also the minutes of the IPP WG meeting indicate that we didn't finish the
security section.

3. Review each of the tables which have conformance requirements for each
attribute and operation.  Certain entries that need special attention are
highlighted (yellow on the screen and color printers, gray on black and
white printers).  

4. Any issues that attendees raise or have been raised on the mailing list.

You should all read the entire document, since I think it is pretty close to
finished, except for any issues that your careful review would raise.
Please send any comments to the DL before the telecon, especially, if you
cannot make the telecon.


The 5 issues are:

1a. Page 8, section 1.3 Namespaces Used:
ISSUE 01: Why can't all of the "ippfax-xxx" attributes defined in this
document be supported OPTIONALLY by an IPP Printer as IPP extensions to the
IPP Protocol as well?  This would allow IPP to support UIF document format
and profiles, along with vCard, and provide a simple way for an anonymous
user mode.  If so, shouldn't we remove the "ippfax-" prefix from all these
attributes in this document, since they wouldn't be restricted to IPPFAX?
>From the TOC, these attributes are:
		4.2 ippfax-uif-profile-requested (type2 keyword) operation
attribute
		5.6 ippfax-uif-profiles-supported (1setOf type2 keyword)
Printer Description attribute
		5.7 ippfax-uif-profile-capabilities (1setOf text(MAX))
Printer Description attribute
		5.8 ippfax-auto-notify (boolean) Printer Description
attribute
		6.1 ippfax-sending-user-vcard (text(MAX)) operation/Job
Description attribute
		6.2 ippfax-receiving-user-vcard (text(MAX)) operation/Job
Description attribute
		6.3 ippfax-sender-uri (uri) operation/Job Description
attribute
		7.2.1.2 ippfax-uif-profiles (1setOf type2 keyword) Job
Creation operation attribute


1b. Page 18, section 6.2 ipp-versions-supported:
ISSUE 02:  OK that the IPP/1.1 "version-number" parameter that contains the
IPPFAX version number is compared with the (existing) IPP/1.1
"ipp-versions-supported" Printer Description attributes that contains the
IPPFAX version number (rather than defining a new
"ippfax-versions-supported" Printer Description attribute and not using the
"ipp-versions-supported" attribute)?

1c. Page 27, Table 7:
Repeat of ISSUE 01

1d. Page 29, Section 9.2, Job Template Attributes, Table 8:
ISSUE 03:  The Sender supply and the Receiver support columns have a lot of
"MUST NOT".  Instead of not allowing these attributes at all, how about a
MAY but restricted to the obvious default values, i.e., "number-up"=1,
"job-priority"=50, "insert-sheet"='none', x-image-shift=0, etc.  Otherwise,
there is some interworking problems with a client or forwarding Printers
that supports both IPP and IPPFAX and supplies these attributes with their
obvious default values (instead of omitted them).

1e. Page 40, section 11.2 uri-authentication-supported, Table 13:
ISSUE 04:  We agreed at the October meeting to make 'none' be "MAY support
and MAY use" for a Receiver.  However, a better way to get public access, is
to use IPP with UIF and vCard exchange. See ISSUE 01 which suggests that
IPPFAX attributes be OPTIONAL IPP attributes as well.  Then 'none' could go
back to MUST NOT.

1f. Page 42, section 11.4 Using IPPFAX with TLS:
ISSUE 05:  OK that we deleted the "ippfax-sending-user-certificate-uri (uri)
operation/Job Description attribute?  The client MUST pass the certificate,
whether by value or by reference in the TLS record layer.  

1g. Page 42, section 11.5 Access Control:
ISSUE 04 (repeated):  Why not use IPP, instead of IPPFAX for anonymous user
access, if we agree to allow all IPPFAX attributes as OPTIONAL extensions to
IPP as well?  

Thanks,
Tom