Subject: FW: IFX> Portland topics [PWG 27/28 June 2002]

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 20 Jun 2002 10:41:31 -0700

Hi folks,

FYI - the agenda for next week's IEEE/ISTO PWG (Printer Working Group)
sessions on IPPFAX (realtime Fax over IPP).

Gail Songer just sent me the plaintext for the (originally) MS Word
attachments, so I've pasted them onto the end of her note below.  

Please see the PWG archives or subscribe to the PWG IFX mailing list 
if you are interested in more information about the IPPFAX project.

	http://www.pwg.org

Cheers,
- Ira McDonald
  High North Inc

-----Original Message-----
From: Gail Songer [mailto:[email-masked]]
Sent: Monday, June 17, 2002 1:48 PM
To: [email-masked]
Subject: IFX> Portland topics

Hi,

I've gone back through the past couple months of emails and tried to get
the highlights of the issues raised on the mailing list. We can use these
as a starting point for our discussions. I've also drawn up a short agenda;
the topics are in no particular order.

Gail

(See attached file: RoyaltyQuestions.doc)(See attached file:
PDFQuestions.doc)(See attached file: Requirements.doc)(See attached file:
Agenda.doc)

-----Plaintext of Attachments-----

[Agenda]

* Requirement check
* Required Formats
o PDF
* Questions for Adobe
o TIFF FX
o IPP Solution - Docs from RonB

----------

[Royalty Questions]

From: Harry Lewis ([email-masked])
Date: Mon May 13 2002 - 18:19:22 EDT 

Scott, thanks for getting back to us. Are you saying Adobe would have no
objection (licensing or otherwise) to the IEEE ISTO PWG basing IPP FAX on
PDF? Are we talking explicitly PDF/X-3 (a pre-press data interchange
subset), another subset (t.b.d.?) or full blown PDF? 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 

From: [email-masked]
Date: Tue May 14 2002 - 17:12:37 EDT 

Scott: 
Just to clarify.... On the adobe website at: 
http://partners.adobe.com/asn/developer/legalnotices.html 
Adobe agrees to royalty free licensing of 
- 5,634,064 
- 5,737,599 
- 5,781,785 
- 5,819,301 
- 6,028,583 
for producing, consuming and interpreting PDF and 
- 5,860,074 
only for producing (not consuming or interpreting) PDF. 
We know that for PDF 1.4 there are additional patents including but not
limited 
to: 
- 6,289,364 
for such things as transparency, etc. 
Now the question...... will all the patents necessary for PDF 1.4 also be
available on RF terms? 
From: Scott Foshee ([email-masked])
Date: Tue Jun 04 2002 - 18:44:40 EDT 

Hi Harry, 
I can not speak for Adobe on this point. My understanding is that we would
offer a license on Adobe's PDF on the same terms as those we offer TC130 in
their development of PDF/X. One of our reps to the Portland meeting is
tasked with sorting this out for IEEE. 
tx....Scott 

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

[PDF Questions]

From: John Pulera ([email-masked])
Date: Wed Jun 05 2002 - 16:44:16 EDT 

In regard to using PDF as the data format for IPPFAX, I remember someone
raising the concern that the data format is not very streamable. According
to the spec (section 5.17) an incremental update at the very end of a big
PDF file can change the way the first page is rendered. Is this still a
concern of the group? This would be an issue for small-footprint
implementations of IPPFAX. Can the IPPFAX spec be written to expressly
require or forbid certain features of PDF? 
John 

From: McDonald, Ira ([email-masked])
Date: Wed Jun 05 2002 - 18:12:49 EDT 

Hi John, 
Yes, the IPPFAX spec can expressly require or forbid certain PDF features.
In particular (I sincerely hope), IPPFAX can specifically cite and require
(for minimum conformance) exactly ONE of the profiles of PDF in the ISO
PDF/X standards. That way we get a stable/tested profile from the pre-press
industry. 
Cheers, 
- Ira McDonald 
  High North Inc 

From: Hastings, Tom N ([email-masked])
Date: Wed Jun 05 2002 - 19:36:32 EDT 

Does anyone know whether one of the ISO PDF/X standards rules out the PDF
construct that causes the streaming problem? If no one responds to the
reflector, be sure to ask the Adobe representative at the meeting. 
Tom 

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

[IPPFAX Requirements]

From: Wagner,William ([email-masked])
Date: Wed May 15 2002 - 15:30:16 EDT 

Lee more concisely expressed the gist of my comment. As a starting point, I
suggest that the intent of IFX is to provide for the secure, verifiable
internet transmission of information necessary to generate a precise
facsimile of an original document (hardcopy or soft) at one or more
authenticated destinations. There are associated functions related to
determining the limits of precision (resolution, color, size, media.) There
are associated functions dealing with notification and verification of
delivery. There is an intent to use the IPP protocol. 

From: Harry Lewis ([email-masked])
Date: Wed May 15 2002 - 15:39:52 EDT 

In light of our full day plenary, I would amend only by adding... 
... with the desire to evaluate the use of the web services Print Services 
Interface. 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 

From: Hastings, Tom N ([email-masked])
Date: Wed Jun 05 2002 - 20:06:20 EDT 

Bill, 
I wonder whether the "term" facsimile brings along with it that the sender
is starting with paper and is re-creating some thing with identical
appearance at the other end? If so, that sort of means scanning. But IPPFAX
(or whatever we want to call it), doesn't require the client to scan
anything. However, maybe your ("hardcopy or soft)" means that either the
sending document and/or the receiving document can be soft copy. Perhaps
this could be made clearer in our requirements. Otherwise, this statement of
requirements seem good to me. Perhaps an additional requirement is that the
sender is able to determine the receiver's capabilities, although maybe that
is a "how" to achieving your requirements. 
Tom 

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