Hi, >That indicates an explicit subscription model from B with an >event type offer from A. Since we don't want our initial >message to get as long as IMAP's,
No, we don't want to destroy SIP's good reputation of having short and compact messages... >I would offer if there are optional things for B to discover from A, it should use >OPTION. No. This is something that can be done per-call basis. We don't want our initial call setups flows to get too long, do we? ;) >That said, I do not see how an unsolicited INFO showing up on A's door could possibly be good, especially if, >as pointed out below, A might not be interested. I didn't say that. It would be useful with negotiation also for INFO. Regards, Christer > Sent from my wireless e-mail device. Sorry if terse. We all > need lemonade: see > <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. > > ----- Original Message ----- > From: Christer Holmberg <[EMAIL PROTECTED]> > To: Eric Burger > Cc: IETF SIP List <sip@ietf.org> > Sent: Mon Oct 15 07:18:20 2007 > Subject: RE: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > > Hi, > > It's not about A knowing what B "needs" - it's about A > telling B that there may be some information he is interested > in sending - IF B wants it. > > Regards, > > Christer > > > -----Original Message----- > > From: Eric Burger [mailto:[EMAIL PROTECTED] > > Sent: 15. lokakuuta 2007 15:00 > > To: Christer Holmberg > > Cc: IETF SIP List > > Subject: Re: What are we arguing about when we say INFO? (was > > Re: [Sip] INFO) > > > > Under what circumstances would A know what B needs, without B > > explicitly signaling B's needs to A? > > > > > > On 10/15/07 3:24 AM, "Christer Holmberg" > > <[EMAIL PROTECTED]> > > wrote: > > [snip] > > > [Christer] One issue with the subscription mechanism is > > that when A is > > > interested to receive events from B it sends a subscription to B. > > > There is basically no good way for A to tell B "Hey, I have some > > > events I would like to send you (if you support them), so please > > > subscribe to them". For some applications B KNOWS it will have to > > > subscribe to certain events from A, but in some cases B may again > > > subscribe to events "just in case". I think it would be > useful if A > > > somehow could indiate which events it expects B to > > subscribe to for this specific call. > > > > > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its > subsidiaries and > > affiliated entities, that may be confidential, proprietary, > > copyrighted and/or legally privileged, and is intended > solely for the > > use of the individual or entity named in this message. If > you are not > > the intended recipient, and have received this message in error, > > please immediately return this by email and then delete it. > > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > > _______________________________________________ > 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 > _______________________________________________ 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
