I'm continuing to revise my posted draft to reflect the comments that folks
have privately sent me over the past weeks to. I hope to have a revision
ready in a week or so.
Many thanks to Ron Bergman for helping a poor fax person navigate the
printer worlds.
######
At 09:25 AM 10/12/98 -0700, Manros, Carl-Uno B wrote:
>IPP - Internet Printing Protocol - Meeting held in Savannah, GA, September
>30 - October 1, 1998
>==================================================================
>Draft-ietf-ipp2ifax-map-01.txt. Can we really notify that the job was
>printed? They can query.
Notification in analog fax is simply we monitor the line till we get a T.30
EOM message on the wire from the recipient that the transmission was
successful and then the transaction is logged by both sender and recipient.
If there was a error that is logged as well.
I'm assuming IPP clients can query that the job was actually printed but in
most cases the fact that "it got there" is enough. The IPP transaction
model in many ways resembles the network fax server model where the fax may
have hit the server on the LAN successfully but had not been routed to the
desktop.
>FAX negotiates prior to sending. They don't get this with e-mail or get it
>very slowly.
Fax negotiates prior to sending. IFAX does not negotiate anything. You
are assumed to have prior knowledge of the recipients capabilities. We
commonly refer to this technique as the "send and pray" method. EMail
capabilities discovery is the subject of several IETF WG's including CONNEG
and MAILCAP which Keith Moore is leading.
>FAX gives confirmation regarding print status. Again, e-mail is slow and
>unreliable for this purpose.
IFAX in its new mode eifax0x.txt [now under review] will mandate options
for both DSN and MDN for confirmation that the message reached the last
SMTP hop and deliver a message if the client was "unable to process" the
message.
>With a Get-Printer-Attributes, an IFAX client could discover which TIFF
>formats are supported.
Yes but in the short run IPP could focus on the Profile F of TIFF
documented in RFC2306 which is 99.9 % of the formats now in use.
>There are other things fax has that may seem foreign to IPP, like
>distributions lists. Some of these may be viewed
>simply as client issues.
Agreed, this is a implementation issue for IPP. It is a serious issue for
SMTP because of the nature of SMTP itself.
>If the device advertises itself as an IFAX capable, it must support the
>required TIFF formats to assure some base
>level of negotiation .
Again RFC2306 is the IFAX baseline. All implementations of IFAX MUST
support this profile.
>If FCC requires date, name and phone number on each page, we have to
>determine whether the sender puts this on
>or the receiver and how to handle potential margin or page scaling issues.
This was covered in earlier messages but the sender watermarks the pages
with the time/date, T.30 CSID, and page numbers. The recipient does not
modify the document at all.
The recipient does log the transaction in the appropriate manner.
My suspicion is that future IPP client implementations could generate a
classic cover page for insertion into the transaction. Margin or page
scaling issues will require some additional study.
>IPP does not mandate creation or completion times. This would be considered
>a serious deficiency for IFAX.
IFAX has the RFC822 headers for the creation data. This has been deemed
sufficient for the purposes of a facsimile service. DSN or MDN will deliver
the completion times.
Any
>IPP printer that supports IFAX would be required to have a real time clock
>to provide this information. On the
>other hand... The generator of the FAX is the one that probably needs the
>clock.
The generator of the fax needs it more ..but the recipient better have it
as well.
Sender and Recipient will need time/date but I believe there has been a
discussion of using RFC867/868 in the absence of a real time clock chip.
>If IPP printer is acting as an off ramp to FAX distribution via GSTN... Then
>the list of names or numbers could
>just be tagged in the URL.
Yes.. there seems to be lots of schemes one could use, one thought would be :
http://domain.com/ipp/FAX=13149189015
where the number is the fully qualified E.164 GSTN number [includes country
codes etc]. This would match some the IFAX gateway addressing schemes
defined in RFC 2303 and 2304.
Its really up to you!
>FAX might also carry additional compression requirements.
Basically for RFC2306 you are looking at MR and MMR for the TIF file. JBIG
and JPEG are defined for the full TIFF spec RFC2301
>Do we assume all legal requirements for FAX pertain to IFAX over IPP even if
>the GSTN is not involved in any
>way?
I have a suspicion that when IPP transactions cross domains, end users are
going to perceive the transactions a "fax" irrespective of the original
intentions of the protocol designers. I think the law of unintended
consequences could come into play here pretty fast.
This is principally a marketing issue, but I can tell you that it has been
our experience with IFAX development that end user perceptions are being
driven by the traditional experience with analog fax.
If it looks like a duck..quacks like a duck ..etc.
The lack of reliable receipt in the first "simple mode" of IFAX sent us all
back to the drawing board.
In addition some of leading edge users of both printer and facsimile
technology have been the legal profession. I believe the more that IPP has
the option to duplicate the "look and feel" of traditional fax the more
successful it will be in the marketplace.
My belief is that the burden of using IPP as a facsimile service falls
principally upon the IPP client software. Perhaps future versions of IPP
clients could select "facsimile service" as an option and offer the end
user the kinds of options they are traditionally used to in fax software etc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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@ix.netcom.com
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<