Jon,
There may be alternatives to INFO for everything in ANSI ISUP, but in ITU-T there is the Application Transport Message (APM). The purpose of this is, ...err..., to transparently transport Application layer information.
I think any new method defined for carrying this would end up with identical semantics to 'INFO restricted to SIP-T' as proposed in Jonathan's draft - namely 'transport of application layer information, with the restriction that the application layer is SIP-T'.
If you wanted to restrict its use to APM, this is something you would restrict at the SIP-T application layer, not in SIP.
...Mark
> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: 30 December 2002 19:46
> To: 'Jonathan Rosenberg'; sip@ietf.org
> Subject: RE: [Sip] INFO considered harmful
>
>
>
> First, I think it is a really good idea to restrict the
> applicability of SIP
> INFO method - I very much agree with the problem defined in
> Section 2 of
> this draft.
>
> That much said, when it comes to solutions I am torn between
> option number 3
> and a more radical alternative - deprecating INFO altogether.
> While it is
> true that INFO was inspired by some of the requirements of
> SIP-T, over time,
> we've found less and less use for INFO. The original vision
> for SIP+ (an
> ancestor of SIP-T) relied on INFO for sending virtually every
> ISUP message,
> but today, there just isn't that much that we do with INFO.
> Practically
> speaking, we could probably find alternatives to INFO for
> carrying ISUP data
> in these cases (which include SUS/RES, INF/INR, some
> provisional response
> cases). Using INFO to send other ISUP messages is frequently
> misguided, and
> can potentially lead to the same sorts of interoperability
> problems we have
> with INFO in other arenas.
>
> Today, however, RFC3398 does allow the use of INFO in these
> three cases, so
> it's simplest to let the INFO method to exist (option 3) for
> the time being
> - but we should be sure to document, even for ISUP
> transmissions, the cases
> in which it is and is not appropriate. In the long term,
> though, I think we
> should just get rid of it entirely.
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Thursday, December 26, 2002 12:12 PM
> > To: sip@ietf.org
> > Subject: [Sip] INFO considered harmful
> >
> >
> > Folks,
> >
> > For some time, I've been complaining about the continued
> abuse of the
> > INFO method for things that should be done other ways
> > (frequently, not
> > using sip at all). I've written up a summary of the problems and a
> > proposed path forward. Specifically, I'd like to obsolete INFO and
> > replace it with a spec that is approved ONLY for SIP-T.
> >
> > Until the I-D appears, you can pick up a version at:
> >
> >
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt
> >
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html
> >
> > Thanks,
> > Jonathan R.
> > --
> > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
> > Chief Scientist First Floor
> > dynamicsoft East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com FAX: (973) 952-5050
> > http://www.jdrosen.net PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>