Tom,
I have the impression that this whole discussion is starting get totally off
track.
If we haven't specified that the "notify-recipient-uri" in the
Get-Notifications, be an ippget URI, it seems to me to be an omission in the
draft text. To my knowledge, it was never the intention to allow anything
else than an ippget URI for this version of notifications, and I am strongly
against now trying to suddenly add new functionality which wasn't intended.
If this discussion continues on this kind of track, we may have to withdraw
the whole spec and start over, to which I would object. Please remember that
you are talking about a document that has been finalized by the IPP WG and
is currently being reviewed by the IESG. If we need to improve some wording
because it is not 100 % clear is one thing, introducing new functionality is
beyond the scope at this stage.
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: Tuesday, July 17, 2001 9:35 AM
To: mjoel@netreon.com
Cc: ipp@pwg.org
Subject: RE: IPP> Re: FW: IPPGET inconsistency on comparing URLs
[polling any kind of URL]
Marty,
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, be
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 ippget
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 types
of Subscription object events, not just ippget events.
This would make IPP notifications more like other notification systems, such
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.
Tom
-----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.
Marty
"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
cc:
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.
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 : Tue Jul 17 2001 - 16:59:46 EDT