Hi Bob,
It's a little more complicated. An Internet 'standards track'
RFC MUST NOT require a URL type outside the IETF standards tree.
So 'ippget:' must not have a hyphen and must be registered in
the IETF tree.
RFC 2717 and RFC 2718 are the normative specs here for URL
schemes.
Cheers,
- Ira
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
Sent: Wednesday, August 23, 2000 2:58 PM
To: McDonald, Ira; Herriot, Robert; Carl Kugler/Boulder/IBM
Cc: pmoore@peerless.com; Harry Lewis/Boulder/IBM; bwagner@digprod.com;
ipp@pwg.org
Subject: RE: IPP> machine readable etc. - why Harry is right
Thanks for discovering that URLs in the IETF tree cannot contain hyphens
(RFC 2717). I had been relying on RFC 2396 which allows hyphens in URLs.
Ned suggested that not have a hyphen.
According to RFC 2717 "ipp-get" would be a member of a new "ipp" tree. It
isn't clear whether this would conflict with "ipp" which will be part of the
IETF tree. But with "ippget" we don't have to deal with this.
Bob Herriot
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> Sent: Wednesday, August 23, 2000 8:07 AM
> To: 'Herriot, Robert'; Carl Kugler/Boulder/IBM
> 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
>
>
> 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 : Thu Aug 24 2000 - 11:15:54 EDT