I generally support the new alternative with the following caveat:
I'd rather get rid of 'collection' (for this use) entirely. If
a client wants more than one Subscription associated with a single
job, then that client can submit the Job with 'job-hold=TRUE' and
create the second through last associated Subscription (or all of
them, having omitted the 'notify-XXX' operation attributes at
Job creation time).
'collection' is a clever idea, but it is also poor man's objects.
I prefer real objects.
And I don't want acceptance of the 'collection' structured
data syntax to hold up acceptance of the IPP Notifications
Extensions by the IETF and non-IPP reviewers.
But I *like* having both Job and Printer subscriptions use the
same object class and not be so different. The complexity
(without this Alternative Proposal) is unreasonably high,
in my opinion.
Cheers,
- Ira McDonald
High North Inc
906-494-2697/2434