Hi Marty,
Careful here - an 'ippget:' URL MUST be a well-formed absolute URL.
Look at the spec. Except that there is NOT any default (well-known)
port, because an 'ippget:' URL is never a communications path, we
adopted the syntax verbatim from RFC 2396 (and 2732 for IPv6).
If you stick arbitrary stuff after 'ippget:' that is NOT of the form
of a well-formed absolute URL as a client, then a conforming IPP
Printer is going to reject your Subscription.
In order for IPPGET to be on the IETF 'standards track', the
'ippget:' URL scheme must be IANA-registered via a published
RFC. That's why we added the section, per IETF requirements.
The URL comparison rules are clear in RFC 2396, so Carl-Uno
has a valid point. Having said all that, I wish we could use
an octet-by-octet comparison because the inquiring Notification
Recipient (who may have been the originating IPP client) SHOULD
treat the string as verbatim and opaque.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc.
-----Original Message-----
From: mjoel@netreon.com [mailto:mjoel@netreon.com]
Sent: Monday, July 16, 2001 5:33 PM
To: ipp@pwg.org
Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs
Hi Carl-Uno, et al,
If the printer were to actually treat the uri as a url, then it would make
sense to follow the comparison rules for urls. Instead, it's really just
an arbitrary string that starts with "ippget:", so I see no problem with a
byte-by-byte comparison, other than the notification spec saying that it's
a url.
Are there any (or will there be any) notification methods in which
notify-recipient-uri will need to be compared using case insensitivity for
a domain name portion? If not, maybe the spec should make it clear that
some methods can consist of a scheme, colon, and arbitrary string.
Marty
"Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com>@pwg.org on 07/16/2001
01:50:52 PM
Sent by: owner-ipp@pwg.org
To: "Hastings, Tom N" <hastings@cp10.es.xerox.com>, ipp@pwg.org
cc:
Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs
Tom,
Are we not going to create possible problems if we specify specific rules
for IPP that differ from normal URL parsing?
Carl-Uno
Carl-Uno Manros
Manager, Print Services
Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, July 16, 2001 1:16 PM
To: ipp@pwg.org
Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs
So OK to delete the section that says that the comparison follows the usual
URL rules so that it doesn't conflict with the other section that says that
the Printer does a straight byte by byte comparison?
Also we should use the term octet by octet rather than byte by byte
comparison.
Tom
-----Original Message-----
From: mjoel@netreon.com [mailto:mjoel@netreon.com]
Sent: Monday, July 16, 2001 11:54
To: ipp@pwg.org
Subject: IPP> Re: FW: IPPGET inconsistency on comparing URLs
Hi Tom,
I'm doing a case sensitive comparison, since the ippget spec says to do a
byte-by-byte comparison and the notification spec says that the address
portion is opaque. I realized that method conflicts with normal URL
comparison rules, but figured that since it was stated, it over-rode the
normal rules.
Marty
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/16/2001 10:50:14 AM
To: "Marty Joel (E-mail)" <mjoel@netreon.com>
cc: "Tom Hastings (E-mail)" <hastings@cp10.es.xerox.com>, "Bob Herriot
(E-mail)" <rherriot@pahv.xerox.com>, "McDonald Ira at Sharp (E-mail)"
<imcdonald@sharplabs.com>, "Ira at Xerox XR&T McDonald (E-mail)"
<IMcDonald@crt.xerox.com>
Subject: FW: IPPGET inconsistency on comparing URLs
Marty,
How is your Printer doing the compare of the "notify-recipients-uri" in the
Get-Notifications Request with the same attribute in the Subscription
objects to see if there is a match?
Do you do any case conversion or not?
IPPGET is self contradictory (see email below).
Here is the extract from RFC 2616:
3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:
- A port that is empty or not given is equivalent to the default
port for that URI-reference;
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
Thanks,
Tom
-----Original Message-----
From: McDonald, Ira
Sent: Monday, July 16, 2001 08:09
To: Hastings, Tom N; Herriot, Robert; McDonald Ira at Sharp (E-mail)
Subject: RE: IPPGET inconsistency on comparing URLs
Hi Tom,
YIKES - I think that octet for octet (not byte, please) comparison is
correct, because for 'Get-Notifications' the URL is an entirely opaque
identifier, right?
Cheers,
- Ira
> -----Original Message-----
> From: Hastings, Tom N
> Sent: Sunday, July 15, 2001 3:00 AM
> To: Bob Herriot (E-mail); McDonald Ira at Sharp (E-mail); Ira at
Xerox
XR&T McDonald (E-mail)
> Cc: Tom Hastings (E-mail)
> Subject: IPPGET inconsistency on comparing URLs
>
> Help! I found that IPPGET says one place that a client or Printer
compares "notify-recipient-uri" URL byte for byte and another place where
it
says it uses the usual URL comparison rules. I suspect that the simpler
byte comparison was done to make it simpler.
>
> Section 5.1 Get-Notifications Request says:
>
> "notify-recipient-uri" (url):
> The client MUST supply this attribute. The Printer object MUST support
this attribute. The Printer matches the value of this attribute (byte for
byte with no case conversion) against the value of the
"notify-recipient-uri" in each Subscription Object in the Printer. If there
are no ...
>
>
> Section 9.5.2 IPPGET URL Comparisons
> When comparing two 'ippget' URLs to decide if they match or not, an IPP
Client or IPP Printer MUST use the same rules as those defined for HTTP URI
comparisons in [RFC2616].
>
> What should we do? I think the byte for byte comparison for comparing
the
URI in Get-Notifications with Subscription Objects makes the most sense.
Correct? There isn't any reason why a Printer would change the URI that a
Subscribing Client supplies in a Subscription Creation operation from that
supplied in a Get-Notifications Request is there?
>
> Thanks,
> Tom
>
This archive was generated by hypermail 2b29 : Mon Jul 16 2001 - 19:55:58 EDT