Hi Gail,
By the way, no answer yet, but IETF 60 was last week,
so IANA is probably pretty overworked. If I don't hear
from them pretty soon, I'll send them a reminder.
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: Gail Giansiracusa [mailto:ggiansiracusa at peerless.com]
Sent: Monday, August 02, 2004 10:40 AM
To: McDonald, Ira
Subject: RE: IFX> FW: Application for port-number (status)
Thanks for doing this Ira!
Gail (Songer) Giansiracusa
Peerless Systems Corp
ggiansiracusa at peerless.com
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Tuesday, June 22, 2004 2:15 PM
To: 'ifx at pwg.org'
Subject: IFX> FW: Application for port-number (status)
Hi,
IANA says below it may take up to 60 days to process
our request for an IPPFAX registered port number.
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: IANA [mailto:iana at iana.org]
Sent: Tuesday, June 22, 2004 11:59 AM
To: imcdonald at sharplabs.com
Subject: RE: Application for port-number (status)
Dear Ira,
We have received your application. Requests are reviewed in
the order they are received. Due to the number of requests we
receive, it may take up to 60 working days to process your
application. We will contact you if further information is
needed.
Thank you,
IANA
-----Original Message-----
From: imcdonald at sharplabs.com [mailto:imcdonald at sharplabs.com]
Sent: Monday, June 21, 2004 3: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