inline
Christer Holmberg wrote:
Hi,
Let's say we have something (not DTMF) that needs to transport jpg
images that are used as soft-key overlays. To do what you're
suggesting, we'd need a new MIME-type registration that says "This is
just like jpeg, except that it is only useful for keypad overlays".
The MIME folks would birth kittens.
I think you may have misunderstood my example here. I'm postulating
that you don't change the MIME type (jpeg) you change the supported/
required header value.
I think that conflicts with the way Supported and Require
work. They both purely say "Can support these options at any
time", not "I expect you to use this particular option's
handling for this particular message"
Let's say you support jpeg for image-mapped touch screen and
jpeg for storing in my pone book and displaying with caller
ID. You'd indicate support for both in "Supported" and would
not reject a request with Require for both.
I send you a jpeg. How do I tell you whether to put it on
your screen as an image map or store it in your phone book?
If the application on the receiving side (or the person your're talking
to) has asked you to send a jpeg, it most likely knows what to do it.
This is similar to when the receiver subscribes to an "jpeg event". The
one sending the jpeg may not know what the receiver is going to do with
it, but the one subscribing to the event knows.
In pretty much all the cases under discussion it is not a matter of
asking a specific question that has one answer, and the mechanisms under
discussion are not equipped for that. Rather it is a matter of
expressing an interest in being notified of a class of things if and
when they happen or come available.
And in Dean's case an interest has been expressed in events serving two
purposes: touch screen maps and caller pictures. It just happens that
both are represented by the same data type.
Matching the delivered information to the particular requested "event
type" is in fact thw problem we are trying to solve. How are you
imagining that this matching is taking place?
Paul
If you send a jpeg just "out of the blue", you may not know what the
receiver is going to do with it. The receiving end may prompt the user
what to do, it may do something by default, etc. That is an
implementation issue - not a SIP protocol issue. SIP is simply used to
transport the jpeg. That is the whole purpose of INFO - sending data
which is not related to the SIP session itself.
Regards,
Christer
_______________________________________________
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
_______________________________________________
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
