Hi Bob and Carl,
I checked on this - IANA registered URLs in the IETF Tree
MUST NOT contain hyphens (see bottom of page 3 in RFC 2717,
Registration Procedures for URL Scheme Names, November 1999).
Cheers,
- Ira McDonald
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
Sent: Tuesday, August 22, 2000 2:50 PM
To: Carl Kugler/Boulder/IBM; Herriot, Robert
Cc: pmoore@peerless.com; McDonald, Ira; Harry Lewis/Boulder/IBM;
bwagner@digprod.com; ipp@pwg.org
Subject: RE: IPP> machine readable etc. - why Harry is right
> -----Original Message-----
> From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
> I like it!
>
> Some minor points:
>
> - In 5. b) the server should terminate the response with a zero-length
> chunk, if Transfer-Encoding: chunked. On receipt of this
> termination, the
> client should close the connection.
I agree
>
> - I think you still need "suggested-ask-again-time-interval" and
> "begin-to-expire-time-interval" to handle the case of really long idle
> times; for example, when subscribing for Job notifications
> on a Job with
> "job-hold-until" specified.
Perhaps this case can be ignored. I was hoping to avoid this complexity, and
I'm not sure if a Printer would want to guarantee to hold on to all Event
Notifications for several hours. Suppose at noon, someone sets
"job-hold-until" to 'night' and then at 4pm changes it to 'evening' or
'no-hold'. If the Printer has told the client to query again at the
beginning of the 'night' shift or even several hours before night shift, the
Job may have completed with many Event Notifications by then.
>
> -Carl
>
> P.S. What is the current "ippget" spec? And is it ipp-get
> or ipp-poll? I
> found a document called ipp-notify-poll on the outside, that is titled
> "ipp-get" on the inside.
It had been "ipp-get", but in Pittsburgh we decided to remove the hyphen.
URLs can have hyphens, but none in the IANA registry have hyphens. We
decided to call it "ippget". So the next release will have "ippget".
Perhaps, you were thinking that "ippget" should be called "ipppoll" and the
one and I am proposing called "ippget"?
Bob Herriot
background:
-------------------------------------------------------------------------
>
>
> "Herriot, Robert" <Robert.Herriot@pahv.xerox.com> on
> 08/22/2000 02:39:24 PM
>
> To: pmoore@peerless.com, "McDonald, Ira" <imcdonald@sharplabs.com>
> cc: Harry Lewis/Boulder/IBM@IBMUS, bwagner@digprod.com, ipp@pwg.org,
> "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>, Carl
> Kugler/Boulder/IBM@IBMUS
> Subject: RE: IPP> machine readable etc. - why Harry is right
>
>
>
> There is a simple extension to "ippget" that does what Harry
> wants. I'll
> call the solution "ippgetw" for "ipp get and wait"
>
> 1. The user subscribes for this Delivery Method in the same way as for
> "ippget" but instead uses the "ippgetw" scheme in the
> "notify-recipient-uri".
>
> 2. The Subscription tells the Printer what Events the listener is
> interested
> in.
>
> 3. The client obtains the Event Notifications by performing the
> Get-Notifications operation with the same URL as in the
> "notify-recipient-uri". This is just like "ippget" except that Event
> Notifications keep coming in the response.
>
> 4. The Printer performs the Get-Notifications operation as follows
> a) it finds all Subscriptions associated with the specified
> "notify-recipient-uri" (like "ippget").
> b) it returns all Event Notifications that it is holding for the
> specified Subscription objects (like "ippget"). This means that
> the client doesn't miss any events between the time of
> Subscription
> and the Get-Notifications operation. This step could be omitted
> if it is OK to lose Event Notifications when the client is not
> performing the Get-Notifications operation.
> c) it returns Event Notifications as they occur (unlike
> "ipp-get").
>
> 5. The Get-Notifications operation terminates in the following ways:
> a) the client closes the connection. The Printer continues to save
> Event Notifications as specified in step 4b) until all
> Subscriptions
> associated with the "notify-recipient-uri" are canceled.
> b) the Printer closes the connection when there are no longer any
> Subscription Objects for the specified URL (in
> "notify-recipient-uri"), e.g. when a Job completes and
> associated
> Subscription Objects are removed.
> c) a time-out or failure occurs. The actions are the same
> as step 5a.
>
> Note: unlike "ippget", the Printer doesn't need to return
> "suggested-ask-again-time-interval" or "begin-to-expire-time-interval"
> because the client performs the Get-Notification operation as soon as
> possible. But according to step b), the Printer does keep Event
> Notifications for a short period of time, at least when there is no
> connection open. The Printer need not keep Event
> Notifications after it
> sends them if there is no requirement for two clients to use
> the same value
> of "notify-recipient-uri" and no requirement for a client to
> get lost Event
> Notification by reopening the connection.
>
>
>
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 11:25:28 EDT