Re: [Sip] Additional uses of INFO

[[e-mail]]

   From: Dean Willis <[e-mail]>

   Ah. You have there the tip of the INFO problem. We don't have a  
   mechanism to answer this question, and if we were going to do  
   anything BUT GTSN using INFO, we'd need to develop such a mechanism.  
   Thus, two choices -- 1) block all further use of INFO, and 2) add a  
   usage-negotiation mechanism to INFO, just as we did for SIP Events.

OK, I'm starting to grasp your point:  The question is not "Are there
ways that one can implement a private extension that will be properly
rejected/ignored by peers that do not implement the extension?" but
rather, "What are guidelines for implementing private extensions so
that they will be properly rejected/ignored by peers that do not
implement the extension?"

Which is not difficult to answer, *once people remember to ask it when
defining an extension* -- see the mechanisms I enumerated in my
previous message.

But the IETF is very good at defining protocols that are astonishingly
robust against extension...  I don't foresee trouble if people lard
all sorts of garbage into SIP, as long as they're reasonably careful.

   Content-type tells about what the content is. Content-disposition  
   tells about what one is supposed to do with the content, and might be  
   a better candidate for this sort of usage. Or perhaps a combination  
   of the two.

   If I send you an image/jpeg during a call, what do you do with it?  
   Display it? Add it to your phone book next to my name? Run a  
   steganographic search on it to look for a hidden message?

Ah, yes.  But I note that you can define x-* Content-Dispositions as
well.  (RFC 2045 via RFC 2183 via RFC 3261!)

For that matter, we should start getting people used to defining
Content-Dispositions to describe the roles of message bodies.  Might I
suggest draft-ietf-sip-hop-limit-diagnostics-03, "Diagnostic Responses
for Session Initiation Protocol Hop Limit Errors", as a good place to
start?  It proposes a message/sipfrag body to the 483 response that
gives the contents of the failed request.  There ought to be a
Content-Disposition to explain the significance of that body.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip