Michael,
Your idea to make each response of a Get-Notifications operation which has
multiple responses (so-called Event Wait Mode), a complete IPP response has
a lot of advantages. Unfortunately, I wasn't able to incorporate it into
the Internet Draft which was due two hours later (which I made by 5 minutes
with the other changes that had been agreed to). However, I will update the
document the middle of this week and publish a new version (even though it
can't be an Internet-Draft until after the IETF London meeting, August
6-10). We can still work on the new draft and that new draft will be for
the IPP FAX WG meeting in Toronto, August 1.
To build on your suggestion:
1. Each response of a multi-response Get-Notifications will be a separate
application/ipp part under a MIME multi-part/related type.
2. Each response will be the usual and complete IPP encoding for a response:
- a "version-number",
- a "status-code", -- that applies to all the events in the part
- the "request-id" that was supplied in the corresponding request
- Group 1: Operation Attributes Group:
"printer-up-time" (integer(1:MAX)) - which is the time that the response is
being sent and goes for all the events that are being returned.
"redirect-uri" (uri) (if redirection needed)
AND we can move the "ipp-get-interval (integer(0:MAX)) back to the
Operations Group, instead of returning it by itself in the last Event
Notification Attributes Group.
- Group 2: Unsupported Attributes Group - if any unsupported attributes
supplied
- Group 3 to N: Event Notification Attributes Group
3. At the end of each response part, we can end with the normal
'end-of-attributes' tag, rather than invent a new 'end-of-part' tag (or have
no tag).
4. Which leaves how to indicate that this is really the last response, i.e.,
that there are no more Subscription objects left that match? Marty Joel
suggests that there be a completely separate response part with its own
status code. The status should be the 'client-error-not-found' which is the
status returned when there are no Subscription Objects found, whether this
is the first Get-Notifications response or the last.
Comments?
I'll produce an updated version of the spec with this idea incorporated
(unless there is objection on the mailing list), towards the middle of this
week. I'll also cleanup some things that I missed in the rush to get the
Internet-Draft out by last Friday, 5:00 EDT. This version will be input to
the IPPFAX WG meeting in Toronto, August 1.
Please send any other comments to the IPP DL on the draft which I posted
last Friday and sent to the Internet-Drafts Editor.
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, July 20, 2001 14:26
To: Michael Sweet
Cc: mjoel at netreon.com; ipp at pwg.org
Subject: RE: IPP> ippget Design Needs Work [use multi-part/related?]
Michael,
You make some good points about having each separate response to a single
Get-Notifications request in Event Wait Mode, be a complete application/ipp
response (from RFC 2911):
- a "version-number",
- a "status-code",
- the "request-id" that was supplied in the corresponding request, and
- the attributes that are REQUIRED for that type of response (Operation
Attributes Group, Unsupported Attributes Group, and Event Notification
Attributes Groups).
We may also want to include a (new) end-of-segment tag (RFC 2910 encoding)
at the end of each response (= a multi-part/related part) but the last which
would end with 'end-of-attributes' tag.
Then the IPP application layer would also know when to start processing
events. Imagine if we also want to convey IPP with a different transport
layer, say, XML. So we would also want an in-band tag to indicate that all
the current events are present.
BTW, I was able to update the draft-ietf-ipp-notify-get-04.txt draft in time
to make the Internet-Drafts cutoff by 5 minutes today. They replied with 4
minutes to go to the 5:00 PM EDT deadline. I included the
multi-part/related, but not repeating the initial stuff each time.
We definitely need more work on this and need to include an example
encoding, complete with multi-part/related headers to make sure we
understand how this works.
Since the IPP FAX WG has agreed that IPPGET is the REQUIRED Delivery Method
for IPPFAX, perhaps they can continue the discussion in Toronto, August 1,
though we definitely should continue on the mailing list as we are as well.
This document is definitely not ready for WG last call quite yet.
Thanks,
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Friday, July 20, 2001 12:06
To: Hastings, Tom N
Cc: mjoel at netreon.com; ipp at pwg.org
Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]
"Hastings, Tom N" wrote:
> ...
> Your idea of using multi-part/related with each part being an
> application/ipp part. The first part is the initial response with all the
> pending Event Notifications (and doesn't end with the
> 'end-of-attributes-tag'). Each subsequent part is one or more additional
> Event Notification Attributes Groups that have occurred as a "bunch" (and
> doesn't end with the 'end-of-attributes-tag'). The last part will contain
> one or more Event Notification Attributes Groups and an
> 'end-of-attributes-tag' when there are no more events possible (all
> Subscription objects in the scope of the Get-Notifications are gone or the
> Printer wants to end wait mode and returns the "notify-get-interval"
> attribute in a separate Event Notification Attributes Group).
> ...
I think that we need to make each part a valid/standard
IPP message of its own:
1. The application/ipp type defines an IPP "message" that
can be a request or response. The format is identical
save for a different interpretation of the operation
or status code field.
2. It will simplify client and server implementations -
only 1 type of IPP data stream needs to be supported.
3. It will allow the parts to be received in any order -
not too important for the current HTTP transport, but
might be important for other types of transports.
4. It mirrors what the mailto and indp methods do - that
is, one standard message format for each collection of
events.
I think the only issue is what the status code field will
contain in the parts - should they all contain the same code,
or should each IPP message contain the current server status
(e.g. successful-ok-too-many-events)?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com