IPP Mail Archive: RE: IPP> Re: FW: IPPGET inconsistency on c

IPP Mail Archive: RE: IPP> Re: FW: IPPGET inconsistency on c

RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs [polling any kind of URL]

From: mjoel@netreon.com
Date: Tue Jul 17 2001 - 13:02:39 EDT

  • Next message: Michael Sweet: "Re: IPP> Re: IPPGET allowing the Printer to request the client todisconnect"

    Hi Tom,

    I don't like it. If a person creates an email subscription, why would they
    then use Get-Notifications to "listen" to that email subscription? After
    all, they're going to get an email. If they want to listen for some other
    event, they can create an ippget subscription. I think the ippget spec
    should say that the notify-recipient-uri passed to Get-Notifications needs
    to have an ippget scheme. What I'd really like, which is probably too
    late, is for the Get-Notifications attribute notify-recipient-uri to be
    changed to notify-recipient, and do a case sensitive comparison to the
    address portion (what follows "ippget:") of the notify-recipient-uri used
    to create ippget subscriptions.

    The other thing I don't like about this spec ambiguity is that it makes it
    more difficult to implement.



    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/17/2001 09:34:55 AM

    To: mjoel@netreon.com
    cc: ipp@pwg.org

    Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs [polling
          any kind of URL]


    Ira, Bob, and I were talking yesterday and we realized that the IPPGET spec
    doesn't require that the "notify-recipient-uri" in the Get-Notifications,
    an ippget URI. It could also be any other scheme, such as mailto or indp.
    In that way, an implementation could allow Notification Recipients to poll
    for any kind of events from any kind of Subscription object, not just
    Subscription Objects. Then a Notification Recipient that missed an Event
    Notification could get caught up. It would mean that a Printer supporting
    Get-Notifications would have to have an event lifetime concept for all
    of Subscription object events, not just ippget events.

    This would make IPP notifications more like other notification systems,
    as SNMP, where there are both events send and a way for recipients to poll
    the recent history.

    What do you think?

    If we clarify this possibility, then it IS important the
    "notify-recipients-uri" be a real URI and follow URI syntax.


    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Tuesday, July 17, 2001 09:08
    To: ipp@pwg.org
    Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs

    Hi Ira,

    It just seems that notify-recipient-uri doesn't really need to be a uri for
    ippget, although the spec can certainly force it to be. I figured that a
    client might want to use a MAC address or an arbitrary string (such as a
    big random number). Of course, if you want to force it to
    ippget:hostname.domainName or ippget:hostname.domainName/arbitraryString,
    then I suppose the uri comparison rules can be enforced, which would
    require hostname.domainName to be compared case insensitively.

    I'm not seeing why notify-recipient-uri has to be a uri, at least not for
    ippget, and in fact I'm not sure why ippget needs to be filed with IETF,
    since it's never used as a uri, meaning that at no time is an ippget "uri"
    used to make a connection or access a resource. The only uri-like thing
    about ippget is that it's used like a scheme in terms of syntax.
    Otherwise, when creating a subscription, if this attribute starts with
    "ippget:" it just tells the server what kind of subscription to create.


    "McDonald, Ira" <imcdonald@sharplabs.com>@pwg.org on 07/16/2001 04:48:11 PM

    Sent by: owner-ipp@pwg.org

    To: "'mjoel@netreon.com'" <mjoel@netreon.com>, ipp@pwg.org

    Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs

    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.

    - 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.


    "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

    Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs


    Are we not going to create possible problems if we specify specific rules
    for IPP that differ from normal URL parsing?


    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


    -----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.


    "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)"

    Subject: FW: IPPGET inconsistency on comparing URLs


    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:



    -----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?

    - 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
    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
    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
    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 : Tue Jul 17 2001 - 13:04:39 EDT