I'm clearly in the minority here, in preferring NOTIFY over INFO.
(Minority of one?)
I agree that it is impossible to make definitive claims that something
is easy to implement when talking about some hypothetical sip stack. So
I will refrain from making such a claim from now on.
I also agree that the name of the method is secondary to getting the
functionality right. So I am fine with leaving the decision about the
method until everything else is worked out.
So, I think the next question is whether there should be a single event
package definition mechanism for this new approach and for the 3265 type
of events, or if these should be entirely disjoint. I realize existing
event package definitions won't be applicable without at least some
tweaks, and not all event types are suitable for both mechanisms. But I
do think there are event types that are suitable for both mechanisms
(e.g. dtmf and dialog) and it would be better if we didn't require
independent definitions for them in both contexts.
What do others think of that?
Thanks,
Paul
Brian Stucker wrote:
-----Original Message-----
From: Michael Procter [mailto:[EMAIL PROTECTED]
Sent: Monday, October 22, 2007 3:01 AM
To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan
Cc: Elwell, John; sip; Adam Roach
Subject: RE: [Sip] INFO
-----Original Message-----
From: Brian Stucker [mailto:[EMAIL PROTECTED]
Sent: 22 October 2007 08:48
To: Paul Kyzivat; Hadriel Kaplan
Cc: Elwell, John; sip; Michael Procter; Adam Roach
Subject: RE: [Sip] INFO
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Hadriel
Kaplan wrote:
-----Original Message-----
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 don't agree that the method won't be hard to support. For
one thing,
many people use stock SIP stacks they got from somewhere
else and have
no idea how to add a new method or usage of a method
because they've
simply never had to do so before or simply can't due to
other issues.
Adding methods or a new nuance to an existing method may
look easy on
paper, but it can be a lot harder to do in practice. Much
harder than,
say, putting code together to toString your registration
entries into
XML for regevent.
On a similar note, I suspect that adding a header (Event?) to
INFO would be simpler than subtracting a mandatory header
(Subscription-State) from NOTIFY, purely in terms of the
support for each in 3rd party stacks.
Of course, I am making a whole bunch of assumptions here that
aren't necessarily true. So maybe this decision can be
postponed until a few more details are ironed out.
In this case, I think it's a pretty safe assumption. Subtracting
mandatory headers from a method is not a great idea because now you've
added a new path in the code where the header is semi-mandatory and the
information to determine when it is mandatory, and when it is not, is
not present in the message itself (so the stack may have to ask the
application what's going on when it's trying to verify that the message
is minimally correct which may not be possible/desirable).
If I get an INFO with an event header in it, and I'm not looking for an
event header in an INFO, then I'm no worse off than I am today, right?
Besides, the event header isn't useful to the lower protocol layers.
It's only useful to the application itself, whereas the
subscription-state header is often handled by another chunk of code
whose sole responsibility is to maintain subscriptions and is neither
part of the stack, nor the application, but used by both.
Regards,
Brian
_______________________________________________
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
