The remaining issues are:
ISSUE 1 - Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability. Which one or
ones should be REQUIRED?
Issue 2 - Should we change the Notification Model to allow notification
delivery methods that are request and response (in addition to the current
model which has only one-directional notification delivery using the
'application/ipp' operation response format?
Issue 3 - If the answer to Issue 2 is yes, should we change the format of
the notification content using 'application/ipp' to always be a (new)
Send-Notification operation request, whether the scheme returns a response
ISSUE 4 - Ok that "job-uri" isn't defined for use with the
ISSUE 5 - Ok that we aren't passing the operation attributes that are copied
to the Subscription object in the new Subscription object attributes group?
Some of the "notify-xxx" attributes aren't Subscription object attributes.
Send any comments to the DL and bring them up at the telecon this Wednesday,