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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Oct 18 21:56:04 EDT 1999


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





More information about the Ipp mailing list