The Abstract should say something like:
The purpose of the INFO request for the Session Initiation Protocol
(SIP), as described by RFC 2976, is to provide mid-session SIP User
Agent (UA)-to-SIP UA application data transport. In the years since
the introduction of the INFO request, experience with the use of the
INFO request indicates a number of problems. This document explains
why there are INFO-based, proprietary protocols in the wild; the
flaws of using INFO; and explains why it is not possible to create a
framework to rescue INFO for general purpose use. Thus, this
document restricts the use of INFO to call establishment signaling,
as described in RFC 3372 (SIP-T).
The INFO method was created as a general transport mechanism in SIP.
As SIP has evolved since then, new mechanisms for different usages
were created. As these mechanisms are now available, this document
formally deprecates the use of INFO for new usages beyond the
existing
standardized ones (i.e., ISUP and QSIG tunnelling).
In section 1, instead of having this rethorical description of why INFO
is useful,
just explain that originally INFO was defined for call associated
signalling
(ISUP and QSIG). Then explain that the mechanism was then used as a
generic SIP
transport because it was there, for DTMF, MSCML, etc.
Then explain that standard mechanisms were defined for DTMF, etc.
I think we need to ditch section 2 altogether ("Flaws with INFO").
That's the
part that people really have problems with.
Then your current section 3 would describe the existing mechanisms. 3.2
should mention
both RFC 2833 and KPML.
I would remove 3.4. Also remove 3.5 (we don't need to be defensive: KPML
would be used here).
Section 4 is OK. I think we should add there IETF will not standardize
any more usages of INFO.
> -----Original Message-----
> From: Eric Burger [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 08, 2007 14:12
> To: Audet, Francois (SC100:3055)
> Cc: IETF SIP List
> Subject: Re: What are we arguing about when we say INFO? (was
> Re: [Sip] INFO)
>
> So, what is missing, or what should be taken out, of
> draft-burger-sip-info?
> I think what you propose is what the document says. Help me out here!
>
>
> On 10/4/07 11:56 AM, "Audet, Francois (SC100:3055)" <[EMAIL PROTECTED]>
> wrote:
>
> > There is a missing point in here.
> >
> > When you say "new uses of INFO are not being accepted by
> the IETF for
> > the following reasons", the problem is that people are overstating
> > their case when discussing the "reasons". This in turn is annoying
> > people who find the "reasons" not technically accurate.
> >
> > I'd rather we try to avoid "inventing" reasons and getting
> into silly
> > long arguments.
> >
> > We could say something very simple in that draft. Something
> like, INFO
> > was created as a general transport mechanism in SIP. As SIP
> evolved,
> > new mechanisms for different usages were created (then we can list
> > them, and give KPML as an example for keypress). And then just say
> > that new usages beyond the existing ones, i.e., ISUP/QSIG
> tunnelling,
> > are therefore deprecated.
> >
> > And leave it to that.
> >
> > Any attempt at inventing complex reasons will just
> encourage people to
> > find flaws in the arguments.
> >
> > But, again, I'm happy with the status quo.
> >
> >> If we had an RFC that said "New uses of INFO are not being
> accepted
> >> by the IETF for the following reasons, please use something else
> >> (like an event package) instead" then people might be less
> tempted to
> >> use INFO, or at least to bring it to the IETF.
> >>
> >> I think we have a consensus on this point. We have some debate on
> >> whether it's worth developing such an RFC, but I think everybody
> >> understands this path.
> >>
> >> However, there's a second problem, and people keep getting
> these two
> >> problems confused (or at least thinking we are discussing
> the first
> >> problem when we're really discussing the second) hence we
> go around
> >> in a circle.
> >>
> >> The second problem is "People are using INFO because it
> has certain
> >> advantages that make it more attractive than a new event
> package for
> >> some applications. If we fixed the problems with INFO negotiation
> >> without losing these advantages, the community would
> benefit greatly
> >> as a result."
> >>
> >> This is the problem whose threads contain things like
> "KPML is a much
> >> less efficient mechanism for driving telephone
> applications that use
> >> DTMF than DTMF over INFO".
> >>
> >> So, there are at least TWO PROBLEMS. Why don't we have at
> least two
> >> solutions?
> >>
> >> Perhaps we could document the flaws with INFO's design and
> explain,
> >> as a BCP, why we don't recommend using it and why IETF should not
> >> proceed with new usages of INFO as long as those flaws persist.
> >>
> >> This would not preclude a second standards-track effort
> (if we wish
> >> to pursue it) to fix INFO, or replace it with a new in-dialog
> >> contextually negotiated content transfer mechanism.
> >>
> >> It would also not preclude standards-track efforts to replace
> >> individual INFO usages with new SIP methods (if we wish to pursue
> >> them). For example, there's no reason why we couldn't
> replace ISUP-
> >> over-INFO with a new SIP method "ISUP", TSIG over INFO
> with a new SIP
> >> method "TSIG", DTMF-over-INFO with a new SIP method
> "DTMF", and so on.
> >>
> >> This gets back to my rant some months ago about the SIP
> community not
> >> having consensus on one extension methodology, thereby giving us
> >> multiple extension methodologies that compete (and possibly
> >> conflict)
> >> with each other. We don't agree whether SIP is an application
> >> protocol or a transport protocol, so we've made it into
> both at the
> >> same time. It's about time we grapple with this issue and
> establish a
> >> practice going forward.
> >>
> >> --
> >> 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
>
>
> 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
