> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > > > the proposal is interesting. > > However there should be cases where you need to send whatever > > information in both directions, or cases where when you send an > > information via Notify you need to receive back some information (e.g. > > the fact that you receive a 200Ok as answer to the Notify it is not > > enough). > > How do you think your proposal should work in those cases ? perhaps > > with > > 2 subscription one in each direction? > > > > Yes, although I prefer to think of it (in this example) as each end > having independently declared a willingness to receive events of the > given package within the current INVITE-bounded dialog. > > It might also be reasonable to envision two different event packages, > designed to work together.
Yeah, IMHO this shouldn't really be Subscriptions with a capital "S", as in rfc 3265, with Subscription state and initial Notifies and all. It's really just info-event-package negotiation. > >> > >> I would argue that it would be nice to have an extension mechanism > >> that allows a UA to be asked "Do you support this specific > >> extension?" without the UA having to encode every extension it > >> supports in every request it sends, but that's a different issue. > > > > that is also something nice. Are you thinking a mechanism like an > > OPTION > > that instead to be general just asks for a specific extension? > > > > Yes, I think that would do the trick. > > Maybe it's just me, but I find the process of including fully- > populated Supported and Allow header fields in every request to be a > bit daunting. Not to mention repetitious, bandwidth and CPU > consumptive, and so on. I don't see how OPTIONS helps in reducing any of that. You'd have to send one for every call. That's more work than a list in a header, no? > SUBSCRIBE gives us something that will do the job. Without preceding > contact, we can ask for a subscription to a package, and get an error > response if it isn't there. And with this new model, you'd not get the info-event-package in responses for the INVITE, and know the same. Well... you'd know for this INVITE-dialog the far end does not support info-event foo. It may for other INVITE-dialogs, but that's arguably more flexible than SUBSCRIBE. > This is a nice property: It keeps us from having to advertise every > event package to which we might possibly accept a subscription in > every message we send. We're only talking about event packages which make sense for INVITE-dialog piggy-backing. This wouldn't apply to things like presence, reg-event, etc. Although I'm not sure how that would be documentable, other than defining something new and distinct from rfc3265 event packages. -hadriel _______________________________________________ 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
