Re: [Sip] INFO considered harmful

["Pete Cordell" <pete@tech-know-ware.com>]

How about we use new methods to define end-to-end application data, but name
the messages INFO-*.  e.g. INFO-MY-FEATURE, so that they can be readily
identified as application data rather than SIP state affecting methods.
Allow: can then be used to negotiate 'INFO' extensions.


- It's easy to parse.

- It's very easy for a stack to treat it generically.

- It can reuse existing SIP features to do negotiation etc.  (e.g. Allow)

- It could be easily documented in the SIP usage document.



My other thoughts on the subject (and what has led me to the above position
are):

- I think its important to have some mechanism that allows end-to-end
application data exchange that is independent of SIP state.

- Doing this in-band (rather than starting up potentially numerous side
connections) will be desirable for some applications (such as those that use
a small amounts of data).

- It seems appealing to be readily able to tell which methods affect SIP
state, and which is application level data.

- Require:, Supported: and Allow: already negotiation of features and where
possible it would be beneficial to re-use these mechanisms rather than
invent new ones..

- An INFO mechanism does not need to offer any semantics beyond simple data
delivery (although it might be nice to have an in-order delivery service?)
(and the afore mentioned negotiation).

- The main problem with INFO is that it doesn't give a single specific way
of identifying which application a particular INFO method is related to.
Hence it necessitates some sort of heuristic procedure to be used.


Some other ways to move ahead might be to:

- Specify that the application that the INFO corresponds to is defined by
the MIME type of the body.

- Define a new header that defines the application that the INFO corresponds
to.

Pete.

----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
To: <sip@ietf.org>
Sent: 26 December 2002 20:12
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