Hadriel Kaplan wrote:
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
I don't think the distinction is significant. Either way it should be
designed to be backward compatible. And neither way will require
actually changing those other documents.
Using NOTIFY:
- will need some new header(s) in INVITE and responses to negotiate this
new capability within the invite dialog usage.
No matter which Method gets used, there will need to be some new header(s) in
INVITE to negotiate. So that's equal.
- once that is done it will have established some new rules for using
NOTIFY in that context. This will not be used unless negotiated,
so there aren't any backward compatibility issues.
- for those that *do* support this, the same code should ideally be
able to use either this technique or real subscriptions, with only
minor tweaks.
I don't see how that's knowable. For one, code is obviously implementation dependent. For another, we would be changing the way in which subscribe bodies could be sent (i.e., they wouldn't, not in the subscription-creation), the handling of subscription duration, and adding a directional negotiation mechanism.
I agree this is speculation.
Lastly, you don't *have* to support rfc3265 at all to support 3261, so the code
change could be quite a bit more.
For somebody that doesn't support 3265, and doesn't want to, but that
does want to support these new packages within an INVITE, this is all
new implementation in any case. Sure, it would require supporting the
NOTIFY *method*, as it is used in this new usage. But the hard work is
in supporting the packages, not the method. And that part is the same
either way.
- I would expect that any event packages defined in the future that
could meaningfully be used in this way would be designed from the
ground up to support both styles.
True of both cases, I presume.
So you are assuming that we would define packages that use a common
encoding and semantics for messages, but that convey them in NOTIFY for
subscriptions and in INFO for invite-dialog usage?
That is certainly possible. It just seems unappealing to me.
Using INFO:
- I don't think it will be sufficient to just add headers to
NOTIFY itself. IMO there still needs to be negotiation of
the particular usages of NOTIFY. So there still need to be
new header(s) in invite and responses.
I'm confused by this - did you mean INFO, and just that the INVITE needs the
negotiation headers (as it does for NOTIFY)?
Sorry - yes I typed NOTIFY where I meant INFO. :-(
- once the negotiation is done there will need to be some new
header(s) to provide added context for the INFO.
- any usage that currently has an event package would have
to be modified to be used with INFO.
Any current event-package could not simply be used in a NOTIFY model either,
for the reason you pointed out in an earlier email: we wouldn't want the
package's subscribe body to be in the Invite. And really there are some that
would be illogical to do so (like reg-event). So in that sense it's a wash:
any current event-package wanting to be used would need an extension to say so
and how, and any future ones would need to define whether or not they support
this new Invite-Notify/INFO and how.
Bottom line - I think a "lighter weight" subscription mechanism serves
all the same needs that an enhanced INFO does, is no harder to
implement, and has other benefits.
That's assuming we need to actually make this create a real Subscription. That
would mean you'd be including all the concepts of Subscribe usages in an
Invite-created dialog, having two usages in the same dialog, etc. Since the
lifetime, relationship, context, usage, etc., between the Invite and
event-notification is inexorably linked, there is no need for a real
Subscription. And we already have a method that has that direct relationship
to Invite: INFO.
By "lighter weight subscription model" I mean negotiating the use of the
event package within the invite dialog usage. Its still a subscription
in some sense, but isn't independently refreshed or expired.
Regardless of INFO or NOTIFY, are we converging on using an adaptation
of the event package template for defining such a thing - one that
ideally would support both styles of usage?
Paul
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
