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