IFX Mail Archive: IFX> FW: Application for IPPFAX port-number

IFX Mail Archive: IFX> FW: Application for IPPFAX port-number

IFX> FW: Application for IPPFAX port-number

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Jun 21 2004 - 16:56:52 EDT

  • Next message: McDonald, Ira: "IFX> FW: Application for port-number (status)"


    I just filled out the IANA form to get a User
    (Registered) port assigned for IPPFAX. They
    say it takes two weeks to process.

    - 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@sharplabs.com

    -----Original Message-----
    From: imcdonald@sharplabs.com [mailto:imcdonald@sharplabs.com]
    Sent: Monday, June 21, 2004 6:55 PM
    To: iana@iana.org; imcdonald@sharplabs.com
    Subject: Application for port-number

    Application for User Registered Port Number
    Name :
    Ira McDonald
    E-mail :
    Protocol Number :
    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:

    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
    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 ?
    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 :

    This archive was generated by hypermail 2b29 : Mon Jun 21 2004 - 16:57:08 EDT