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 - 16:17:30 EDT