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.
I am not objecting to that.
>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.
I agree to that also. But, even in the subscription case it is not the SIP core
protocol which indicates what to do with the data - it's the event type, or
some information element within the event.
Regards,
Christer
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
