IPP Mail Archive: IPP> Re: FW: IPPGET inconsistency on compa

IPP> Re: FW: IPPGET inconsistency on comparing URLs

From: mjoel@netreon.com
Date: Mon Jul 16 2001 - 14:53:55 EDT

  • Next message: Hastings, Tom N: "RE: 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 - 14:56:42 EDT