ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-991014.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-991014.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-991014-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-991014-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-spec-01.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-991014.txt
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
or not?
ISSUE 4 - Ok that "job-uri" isn't defined for use with the
Create-Job-Subscription operation?
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,
10/20/1999.
Thanks,
Tom