Hi,
I just filled out the IANA form to get a User
(Registered) port assigned for IPPFAX. They
say it takes two weeks to process.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: imcdonald at sharplabs.com [mailto:imcdonald at sharplabs.com]
Sent: Monday, June 21, 2004 6:55 PM
To: iana at iana.org; imcdonald at sharplabs.com
Subject: Application for port-number
Application for User Registered Port Number
Name :
Ira McDonald
E-mail :
imcdonald at sharplabs.com
Protocol Number :
TCP
Message Formats :
IPPFAX/1.0 (see below) uses identical message encoding to IPP/1.1 (i.e., it
runs on top of HTTP/1.1 and TLS/1.0). But IPPFAX/1.0 requires that TLS/1.0
be started _before_ the HTTP/1.1 layer connection starts - whereas, IPP/1.1
Encoding (RFC 2910) uses Upgrade (RFC 2817) to start TLS/1.0 after HTTP/1.1.
The latest IPPFAX/1.0 working draft is at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/wd-ifx10-20040524.pdf
Message Types :
All IPPFAX/1.0 operation requests are HTTP/1.1 requests and all
IPPFAX/1.0 operation responses are HTTP/1.1 responses.
The IPPFAX/1.0 mandatory subset of IPP/1.1 Model (RFC 2911) messages is:
Get-Printer-Attributes, Get-Job-Attributes, Get-Jobs, Print-Job and
Cancel-Job.
Message opcodes :
See (3) above. The actual protocol numbers for op-codes and attributes
are already assigned for IPP/1.1. There are a few new IPPFAX/1.0 Printer
attributes that we will register with IANA in the IPP Registry after we
'last call' IPPFAX/1.0 in the IEEE/ISTO PWG.
Message Sequences :
Client MAY first send a Get-Printer-Attributes request and then wait for
a Get-Printer-Attributes response. Client MUST send Print-Job to submit
a network fax. Client MAY send Get-Job-Attributes to verify successful
processing (e.g., all pages printed in output bin). Administrator ONLY
MAY send Get-Jobs (to read job list) and Cancel-Job (to purge a bad job).
Protocol functions :
Realtime network facsimile service over the Internet by re-using existing
IPP/1.1 (RFC 2910 / RFC 2911) messages and encoding.
Broadcast or Multicast used ?
no
How and what for Broadcast or Multicast is used (if used):
Description :
This port will be used only for TCP connections from IPPFAX/1.0 Senders
(end user or administrator clients) to IPPFAX/1.0 Receivers (servers). The
TCP connection will be immediately followed by a TLS/1.0 egotiation.
Then an HTTP/1.1 connection will be completed.
An IPPFAX/1.0 Receiver will have the apparent functional behavior of a PSTN
facsimile device: (a) highly available at a well-known address; and (b)
very difficult to corrupt by any intermediate attacker (due to the TLS/1.0
data integrity services).
An IPPFAX/1.0 Receiver MUST always strongly authenticated during TLS
startup, with a certificate. An IPPFAX/1.0 Sender (client) MAY be strongly
authenticated during TLS startup. Thus, a legally verifiable
transmission is possible.
IPPFAX/1.0 Senders MAY all send vCard (RFC 2426) sending-user-vcard
and receiving-user-vcard Job attributes to provide detailed source and
destination labelling (e.g., for routing of the hardcopy fax).
IPPFAX/1.0 is intended to leverage the widespread current adoption of
IPP/1.1 in network printers and to offer a significant improvement over
Internet Fax over SMTP (RFC 2305) in reliability and timeliness.
Name of the port :
PWG IPP Facsimile
Short name of the port :
pwgippfax