one more
Carl-Uno Manros
10701 S Eastern Ave #1117
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-310-251-7103
Email carl@manros.com
-----Original Message-----
From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
Sent: Tuesday, April 02, 2002 11:55 AM
To: McDonald, Ira
Cc: 'ned.freed@mrochek.com'; McDonald, Ira; 'carl@manros.com';
'bob@herriot.com'; 'hastings@cp10.es.xerox.com'
Subject: Re: Did you comment on IPP URL Scheme?
> Hi Ned,
> During the IETF 'last call' on the IPP URL scheme (December 2001), did
> you have any specific comments we should address?
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-url-scheme-04.txt
> (10 January 2002)
I posted the following comment to the list on 10-Jan-2002:
This document should make it clear that it updates RFC 2910.
This document repeatedly says that both RFC 2373 and RFC 2732 update
RFC 2396, but only RFC 2732 actually does this. As such, only RFC 2732
should be listed.
Section 4.1 should make it clear that this URL scheme is used to designate
entities that implement the IPP protocol rather than being used as an IPP
protocol element.
The same paragraph occurs 4 times in the document: the first
2/3 of the abstract, and in section 1, 4.5, and 6. Repeating something in
the
in the document proper, but the other repetitions should be eliminated.
There are no examples of URLs referring to jobs, only several examples of
URLs
referring to printers. Jobs seem like a much more interesting use of ipp
URLs,
especially returned in the job-uri: response to a job submission, so
examples
of them should be included if possible.
The second paragraph of section 4.5 appears to be a repeat of section 4.1,
and
should be removed.
The title of section 4.5 is "IPP URL Scheme Syntax in ABNF" but the section
includes a lot of material besides the ABNF. "IPP URL Scheme Syntax" might
be a better title.
The second paragraph of section 4.5.1 uses the term "may represent" in a
couple
of places. This makes it sound like (a) These are the only possible
functions
of the last element of a URL and (b) Only the last element of the URL can
perform these functions. One possible way to make this clearer would be to
say
"might represent" rather than "may represent".
Section 4.5.1 includes several examples of IPv6 URLs near the end. It is
intended that explicit IPv6 URLs will only be used in emergencies, so it
isn't
appropriate to include such examples in this document.
Security considerations for URL schemes may be different than security
considerations for the protocols that the URL schemes designate. There are
a
set of questions associated with URL schemes in section 2.4 of RFC 2718
that
should be answered in this document.
Security considerations for URL schemes may be different than security
considerations for the protocols that the URL schemes designate. There are
a
set of questions associated with URL schemes in section 2.4 of RFC 2718
that
should be answered in this document.
As far as I can tell you haven't addressed a bunch of these.
Ned
This archive was generated by hypermail 2b29 : Tue Apr 09 2002 - 22:44:18 EDT