IPP Mail Archive: IPP> NOT - Updated Notification spec posted with agreements from Denve

IPP> NOT - Updated Notification spec posted with agreements from Denve

Hastings, Tom N (hastings@cp10.es.xerox.com)
Mon, 18 Oct 1999 18:56:04 -0700

I've updated the Notification spec with the agreements on the issues from
the Denver meeting:

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