Hi Nancy,
[copying the IPP list because this yours are good questions]
No - IPP/1.0 (RFC 2566) does NOT define or support "ipp:"
URI scheme - that's why the IESG put a very strong note of
disapproval on the cover page and forced IPP/1.0 to be IETF
Experimental and not IETF Standards Track.
IPP/1.0 (which uses only overloaded "http:" URI scheme) is
IETF Obsolete and should not be implemented (it's a major
security leak - because it typically uses port 80).
----------------------
Unfortunately IPP/1.1 (RFC 2911) only *names* the "ipp:" URI
scheme, but does NOT define it at all (even in RFC 2910).
The "ipp:" URI scheme was finally defined (with ABNF) and
registered with IANA 3 years later in RFC 3510 (I wrote this
one with help from Bob Herriot).
------------------------
YES - the "ipp:" URI scheme supports the simple form:
ipp://IPaddress
See section 4.5. IPP URL Scheme Syntax on page 5 of
RFC 3510.
BUT in section 4.6. IPP URL Examples on page 6 it warns:
"Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPP URLs."
That was at the specific direction of the IESG - literal IP
addresses don't pass through any of the security checks
of a dereferenced DNS name (valid local domain, etc.)
and they are fragile in a DHCP-based environment.
-----------------------
NOTE: When we revise IPP/2.0 next year to add new version 2.2,
I plan to add normative text which says that ONLY the "ipp:" URI
scheme MUST be used for Printer or Job URI values (for version
2.0 and higher).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Thu, Sep 17, 2009 at 12:13 PM, <Nancy.Chen at okidata.com> wrote:
>> Hi Ira, Tom, and Pete,
>> I am wondering whether you still remember the URI scheme supported by IPP
> 1.0. Does it support this format:
>>ipp://IPaddress ?
>> Does IPP1.1 require to support this format?
>> -Nancy
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.