All three values for 'uri-authentication-supported' (including
the cleartext 'basic') make sense, because the 'ippfax:' URL
MUST use TLS (or SSL3, for compatibility) per Table 15 of
But there is an error in Table 15 - it allows the Sender and
Receiver to support and use 'none' for security. This is
wrong. It violates the intent that 'ippfax:' URLs MUST
always use data integrity and MAY use data privacy (i.e.,
encryption of data contents and not just the integrity
If TLS is not used for an IPPFAX-like service, then the URL
MUST be an 'ipp:' URL and NOT an 'ippfax:' URL.
When we ask IANA for a new standard port for 'ippfax:' URLs,
we have planned to state that TLS/SSL3 MUST always be used
on those URLs. On previous IPPFAX telecons, we have considered
that the behavior COULD be just like 'https:' - that is, the TLS
session is always immediately started, not negotiated to start
via the HTTP 'Upgrade:' header.
- Ira McDonald
High North Inc
From: Hastings, Tom N [mailto:email@example.com]
Sent: Tuesday, December 11, 2001 9:22 PM
To: Gail Songer
Cc: IPP FAX DL (E-mail)
Subject: IFX> RE: Receiver Requirements for Certificate
Table 13 Authentication Requirements in section 11.2
uri-authentication-supported says that a Receiver MUST support and MAY use:
Does this seem reasonable? If not, then lets raise it as an ISSUE.
From: Gail Songer [mailto:firstname.lastname@example.org]
Sent: Thursday, November 29, 2001 14:15
To: Hastings, Tom N
Subject: RE: Certificate
Table 13 states that a receiver must support "Digest" and "Certificate". I
was wondering what we are requiring the receiver to support.
This archive was generated by hypermail 2b29 : Wed Dec 12 2001 - 12:19:53 EST