While I agree that INFO does not solve the problem raised in this draft,
I think the problem space is sufficiently similar that it is worth
looking at what we did for INFO-events, and whether similar things would
be needed here.
Both INFO and UUI are similar in that:
* they carry information that is opaque to intermediaries; the
intermediaries just carry the data
* the information is 'application oriented' in nature
* the contents themselves can be lots of different things, oftentimes
not even standardized
For INFO, we all seemed to agree that what we needed was some clear way
of carrying meta-data about the content. In particular:
* an 'event-like' parameter for typing the data
* content-type to allow decode
* content length
It seems to me that, all of the same reasons we wanted a framework for
INFO, apply here too. Are we not concerned that an INVITE might get
forwarded somewhere not quite intended, and something will get that UUI
and not know what to do with it? Or worse, mis-parse it and do the wrong
thing?
Is there a need for some kind of scoping? A way to have proxies or SBCs
remove UUI when it leaves a perimeter of trust, ala spec-T?
I understand that these features are not present in ISDN; however, SIP
networks are not the same as circuit networks, and the likelihood that
UUI 'escapes' and goes somewhere unintended seems much higher to me in
SIP. I can see lots of uses for this mechanism, and would hate this turn
into our next INFO-disaster.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
jdrosen@xxxxxxxxx
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
