On Jun 15, 2007, at 9:58 AM, Paul Kyzivat wrote:
There is a big difference between specific additional uses, defined
on a one-by-one basis, and *generic* usage.
I don't know how to view generic usage as anything but an explicit
move to support SIP as a tunneling protocol. And I think that is
something that many people here *don't* want it to become.
Opening it that way would pose many of the same issues that the
Service-ID did.
I'd argue we already used that can of worms for fishing when we did
RFC 3265. Event packages provide a nice way of using SIP as a
transport protocol, wrapped up with nice safety padding so one is
less likely to hurt one's self using them and so that the application
using the transported data is properly isolated from the SIP state
machine.
The real question is whether there's a real requirement to do the
same thing for INFO.
As has been pointed out, it's possible to do anything that you can do
with INFO by doing a set of subscriptions (possibly MANY
subscriptions) in parallel to an INVITE dialog usage. Especially
since GRUU gives us a way to make the subscription endpoints the same
as the INVITE endpoints.
So we're just talking about efficiency here, not functionality.
With what we've been talking about with INFO, it should be possible
to declare support for many different INFO usages within a single
INVITE dialog. This has the potential to make the INFO approach
substantially more message-efficient than SUBSCRIBE/NOTIFY, which in
most cases is going to require at least one subscription in each
direction, and in some cases many subscriptions in each direction.
The real question -- aside from the officially-sanctioned PSTN
transport and the unsanctioned (and NOT GOING TO BE SANCTIONED BY
THIS WG) DTMF are any applications being developed that need this
sort of efficiency?
My personal feeling is that if it is available, INFO will be used.
Sometimes wisely, sometimes unwisely. But I can imagine myriad
applications that could usefully accompany a multimedia session with
little snippets of data being schlepped back and forth. I can also
imagine doing the same thing with a parallel MSRP session.
--
Dean
_______________________________________________
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
