Another advantage of having two Subscription Template attributes, one for
pull methods and one for push methods:
"notify-recipient-uri" (uri) for push methods
"notify-pull-method" (type2 keyword) for pull methods
is that such bi-directional protocols, such as ftp, can be defined as two
separate IPP Delivery Methods, one for push and one for pull.
In the case of the push method, the uri is "ftp://..."
In the case of the pull method, the keyword is 'ftp' or maybe 'ippftp'.
Again each Subscription object MUST have one or the other, but not both
Subscription Template attributes.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Friday, October 26, 2001 18:38
To: Michael Sweet; McDonald, Ira
Cc: ipp (E-mail); IPP FAX DL (E-mail)
Subject: IFX> RE: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget'
URI
I like what you guys have come up with. Thanks.
I assume that the standard keyword value for "notify-pull-method" would be
'ippget', right?
One question:
Why have the "notify-pull-method" Subscription Template attribute by
multi-valued?
For example, if 'ftp' were made a second pull method, then that is
requesting the Printer to put some sort of file that the Notification
Recipient is going to pull. And I guess that the Event Life time would have
to be the same for both pull methods, since we have only one
"ippget-event-life" Printer Description attribute. Or would we have one for
the 'ippget' method using the Get-Notifications operation and one for FTP so
we'd need another, say, "ftp-event-life" Printer Description attribute?
If the Event Life's are different, I would think it might be problematic to
have a single Subscription object for both methods. So how about
simplifying the "notify-pull-method" Subscription Template attribute to be
single valued? If you want both, the client has to create two Subscription
Objects.
Comments?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Friday, October 26, 2001 13:29
To: McDonald, Ira
Cc: Hastings, Tom N; ipp (E-mail); IPP FAX DL (E-mail)
Subject: Re: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI
"McDonald, Ira" wrote:
>
> Hi Michael,
>
> First, I suggest that any Subscription with a missing/empty
> "notify-recipient-uri" MUST support retrieval of those
> notifications via IPPGET in-band and MAY support one or
> more other client pull methods for notification retrieval.
Sounds reasonable.
> Second, I agree that we have an ambiguity about WHICH are
> the supported client pull methods, so how about a second
> attribute (strictly alternate to "notify-recipient-uri",
> so that one or the other MUST be in every Subscription),
> called "notify-pull-method (1setOf keyword)", so that the
> Printer attribute "notify-pull-method-supported" can enumerate
> all the client pull methods supported by an implementation.
That'll work, thanks!
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Tue Oct 30 2001 - 20:59:18 EST