Thanks for your quick reply. I was just about to send an email to Tom
Hastings stating that he must have missed the discussion on "job Ticket"
and VCARD. As you stated "Job Ticket" is an IPP term, although a formal
definition is not established. We also located the RFCs for VCARD and
they should also have been included in the minutes.
The VCARD document is RFC 2426 and RFC 2425 is a supporting document.
(Thanks to Ira Mcdonald for the RFC numbers.)
I am looking forward to your updated document. In the interium, I am
spending as much time as possible getting up to speed on fax. Can anyone
recommend a good text book or a reference on the Internet?
On Wed, 14 Oct 1998, Richard Shockey wrote:
>> 3 IFAX and IPP compatibility
>> Ron Bergman reviewed the results of Richard Shockley's document
> examining the suitability of using IPP for IFAX.
>> Q: Ron clarified that what IFAX means by re-direction is quite different
> from what HTTP means by re-direction. For IFAX re-direction means
> either (1) that the phone number can be included in the URL explicitly,
> or (2) that a URL can represent a phone number or a set of phone numbers
> implicitly. In either case the IPP Printer object would dial the
> appropriate phone numbers to make the connection, after receiving the
> print job.
>> REPLY: Yes... this is what we mean by redirection. I will need to study
> further what is permissible in URL's and how the server accepts that
> data..but this is essentially correct.
> A practical example would be that I access my enterprise IPP server located
> in NYC from London and instruct it to "output" the print job to 14153334545
> in California etc. The IPP server in essence relays the transaction over
> the GSTN to its intended destination. The methodology and or syntax for
> inclusion of E.164 numbering in IPP URL's should be a action item.
>> But there might be another context as well .. say I have a IPP address
> printed on my business card. I then instruct my IPP server to convert all
> transactions to SMTP IFAX since I happen to be on the road from Monday
> through Thursday and I want to see my faxes in my mail box..
>>> Q: One of the attractions of using IPP for IFAX, is that the client can
> query the IPP Printer for the supported document-formats and other
> capabilities. With IFAX over e-mail, the sender has to assume TIFF/F.
>> REPLY: Yes exactly ..as I posted in a earlier message all IFAX transactions
> must support Profile F of TIFF as the minimum subset. Anything else is
> "send and pray".
>> Q: Only if the sender knows that the recipient supports TIFF/FX, can it
> send TIFF/FX. Supporting query with e-mail is very problematic.
>> REPLY: Problematic is a polite way of putting it. This is a area where
> there is a lot of work underway, re previous posting.
>> ACTION ITEM (Ron): Find out more about what IFAX means by "Job
> Ticket". Richard's document mentions "Job Ticket" and "VCARD" which is
> virtual (business) card.
>> REPLY: Job Ticket is a IPP term...perhaps I have misunderstood its use. I
> could use some help here understanding its IPP context . I believe it is a
> vendor implementation issue???? I was using it to look at as a "de facto"
> cover page or as an alternative to IPP client cover page generation. This
> may be incorrect. If IPP is used in a "facsimile service" context then IPP
> clients SHOULD be able to generate a cover page into the stream to satisfy
> appropriate legal requirements etc.
>> VCARD is a standard which is essentially a MIME attachment to EMail that is
> used to provide extended sender identification to the recipient (business
> card data). VCARD is a potentially useful tool to permit senders and
> recipients more detailed information if such a desire exists. It is
> currently implemented in the Netscape Mail client and I believe MS Outlook
> as well.
>> In my next revision I will try to distinguish the difference between IPP as
> a "facsimile service" which essentially means conformity to the legal
> requirements of FAX as is currently customary and inter operability with
> the GSTN/IFAX environment which would mean at minimum supporting the
> RFC2306 TIFF/F profile in driver implementations.
>> Is any of this helpful?
> Richard Shockey
> Shockey Consulting LLC
> 8045 Big Bend Blvd. Suite 110
> St. Louis, MO 63119
> Voice 314.918.9020
> Fax 314.918.9015
> INTERNET Mail & IFAX : rshockey at ix.netcom.com> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<