Attendees: Ira McDonald (High North), Gail Songer (Netreon), Marty Joel
(Netreon), Cark Kugler (IBM), Scott Foshee (Adobe), Tom Hastings (Xerox).
Summary:
We discussed IFX Issues 32-42 and 44. We also discussed Adobe's IPR
concerns about the TIFF license granted to the IETF. We agreed to have
another telecon to resolve the remaining IFX issues:
Friday, August 17, 10-12 AM PDT (1-3 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
10-11 AM - Address the concerns about UIF and the Adobe IPR issues with
TIFF/FX.
11-12 AM - continue with IFX issues 43, 45-47.
Details:
Scott Foshee from Adobe joined us for the entire telecon and explained that
he is the Adobe contact person for TIFF. At the end of the telecon, he told
us about last week's IETF FAX WG meeting at the IETF meeting in London. He
told us that Adobe had raised to the IESG and IAB their concerns about the
TIFF license that they had granted to the IETF for use in TIFF/FX. Scott
explained that the IETF FAX WG is likely to split the TIFF/FX document into
two parts, one part that is compatible with existing TIFF readers (probably
profiles S and F) and the other that has the extensions (probably profiles
J, C, L, and M). He suggested that this Internet FAX changes might impact
our IPPFAX schedule.
He also explained that the IEEE-ISTO would probably need to get a license
from Adobe for TIFF for use with UIF.
We also talked about the possibility of using PDF/X.1 (an ISO standard)
instead of or in addition to UIF. Scott will pass this possibility on to
the Acrobat Group in Adobe to see if they want to come join the IPP FAX WG.
Scott will be on vacation starting Thursday, August 16, returning September
6.
For the first 110 minutes of the call, we continued reviewing the IFX issues
on the IFX spec version D0.6, posted 7/27:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
IFX Issues 1-31 were covered or postponed at the Toronto meeting. See the
minutes at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.docftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf
The remaining ISSUES in the IFX document are issue 32-41.
Issue 42-47 have been added since the meeting this week in talking with
Marty and Ira about the good agreements reached in Toronto (Issue 43 and 44
have been slightly augmented from the previous agenda, so please use this
agenda):
ISSUE 32: Do the conformance requirements look ok?
The conformance section has many changes, since we have agreed to many
changes:
1. The Sender MUST supply and the Receiver MUST support the
"ippfax-semantics" operation attribute in all operations to get the IPPFAX
semantics as described in section 3.2.
Now its the IPP versus the IPPFAX URL that controls the semantics.
2. The Sender MUST query and the Receiver MUST support the attributes
using the Get-Printer-Attributes operation as described in sections 4 and 5
and Table 1.
Toronto: agreed that the Sender MUST either query as above or use the
Validate-Job operation.
3. The Sender MUST supply and the Receiver MUST support the
operation/Job Description attributes for Identify Exchange as described in
section 6.
Toronto: agreed that its a MAY for the Sender and a MUST for the Receiver.
4. The Sender MUST support submitting and the Receiver MUST accept
IPPFAX Jobs as defined in section 7 and Table 2, Table 3, Table 4, and Table
5.
Still true subject to the changes.
5. The Sender MUST place the Sender's identity on every page as
required in section 7.8.
Still true, but agreed that the Sender's identity is the same value as the
"ippfax-sender-uri" (uri) operation/Job Description attribute. Need to talk
to Lloyd about what FAX identity is legally binding. We should leverage the
legal status of FAX identity.
6. The Sender and Receiver MUST support the operations as indicated in
section 8 and Table 6.
We agreed that the entries in Table 6 need three columns for the Receiver:
job owner, operation, other and that there are entries which say MUST, MAY,
and MUST NOT. ACTION ITEM (Tom Hastings): propose the contents of these
columns to the DL based on the discussion. For example the Receiver MUST
NOT accept Cancel-Job for the owner and others, but MAY accept for the
Operator. The Receiver MUST accept Get-Subscription-Attributes and
Get-Subscriptions for the owner. We also agreed that a user doing a
Get-Job-Attributes or a Get-Jobs on an IPP URL MAY see IPPFAX jobs, just
like any other non-IPP protocol. However, certain attributes, such as
"job-name", and "job-originating-user-name" MUST NOT be returned.
7. The Sender and Receiver MUST support the security mechanisms
indicated in section 9, including TLS.
No change.
8. If the Sender and Receiver support Off-Ramps, they must support the
attributes defined in section 10.1.
Off-ramps have been deleted from this document. We may put them into a
separate document as an OPTIONAL extension, if there is interest.
Need to register the new attributes and the new status code. Text TBD.
ISSUE 33: Need version 3.0 of vCard, since it an RFC, while version 2.1
is not.
Unresolved. ACTION ITEM (Ira): Find out how widely the vCard 3.0 is
deployed.
vCard version 3.0 is RFC 2426 "vCard MIME Directory Profile", F. Dawson, T.
Howes. September 1998. (Format: TXT=74646 bytes) (Status: PROPOSED STANDARD)
ISSUE 34: Is this example accurate? The phone number format seem wrong.
At least fix phone number to use "-" to be correct.
ISSUE 35 (repeat): What vCard restrictions? No pictures, no logos, no
sound?
Receiver is not required to store pictures, logos, and sound on the Job
object (but Sender MAY include).
ISSUE 36: What other Receiver attributes should go in the Generic Directory
Schema for an IPPFAX Receiver?
These look fine, except "ippfax-semantics-supported" is gone, since
"printer-uri-supported" tell whether or not ippfax is supported by the
scheme.
Also a Printer that supports both IPP and IPPFAX should advertise them
separately, since they are separate services.
Finally, an IPPFAX Printer advertises document-format-supported as the
formats that it supports for the IPPFAX service. If an implementation
and/or an administrator wants to support additional document formats, such
as Postscript, that don't have the guarantees that UIF has, then the Sender
MUST query the User before sending the document. We'll still call this
fallback, since fallback to IPP has gone away with having separate URLS for
IPP versus IPPFAX.
ISSUE 37: OK that it is of abstract type printer?
Yes, though in the future, it could also be fax.
ISSUE 38: Should the concrete type be 'IPP' (since the 'ipp' scheme is
being used), or 'IPPFAX' to differentiate it from an IPP Printer?
The concrete type MUST be ippfax to agree with the new scheme.
ISSUE 39: Is the conformance right?
Looks ok.
ISSUE 40: Should we add authors to PWG standards like we do IETF RFCs?
Yes.
ISSUE 41: Should we add participants to PWG standards like we do IETF RFCs?
Yes.
The following NEW issues were discovered by Marty Joel, Ira, and myself when
going over the ISSUE resolutions from the meeting.
ISSUE 42: What attributes, attribute values, and operations does a client
see with Get-Printer-Attributes depending on the URL being used (independent
of whether or not we have a new URL scheme - see ISSUE 03)?
On the IPP URL, the client sees IPP, but NOT IPPFAX attributes. On the
IPPFAX URL, the client sees IPPFAX attributes, plus all of the IPP
attributes, but with values that pertain to IPPFAX.
ISSUE 42a: According to IPP/1.1, the three parallel "printer-uri-supported",
"uri-security-supported", and "uri-authentication-supported" (the three
musketeers) always returns all values for all schemes, so these three
attributes aren't colored in any way, right?
Yes.
ISSUE 42b: If a single Printer object supports IPP and IPPFAX with separate
URLs, and a client queries on the IPP URL, does it get back the "ippfax-xxx"
attributes or not?
It does NOT get back "ippfax-xxx" attribute on the IPP URL.
ISSUE 42c: If we have a separate URI scheme (ISSUE 03), then there is no
need for the newly renamed "semantics-supported" (was
"ippfax-semantics-supported") Printer attribute at all? Instead, the
"printer-uri-supported" serves the same purpose. However, if we don't have
a new IPPFAX URL scheme, will the "semantics-supported" Printer attribute
act like the three musketeers and return all semantics supported no matter
on which URL the client queries?
We are going to get a new scheme and either have a well know system port
(less than 1024) or at least a well know port (1024 to 32K range).
...
ISSUE 44: If we do have a new 'ippfax' URL scheme, then the scheme
indicates whether IPP or IPPFAX semantics are wanted, right? Then
"ippfax-version" operation attribute (decision on issue 11 to replace the
"ippfax-semantics" operation attribute), only becomes a version indication,
and NOT a request to use IPPFAX semantics, right?
Yes, "ippfax-version" only indicates the IPPFAX version and the URL
indicates whether IPP versus IPPFAX semantics are to be used. If a Sender
sends an "ippfax-version" operation attribute on an IPP URL, the Receiver
MUST still accept the request, but return it as an ignored attribute.
ISSUE 44a: If we don't have a new 'ippfax' URL scheme, then which URL the
client supplies still indicates whether IPP or IPPFAX semantics are wanted
for all operations, right? Its just harder for the client to tell which
URL to use in order to get IPP versus IPPFAX semantics.
Moot, since we've agreed to have a new URL scheme.
End of telecon.