| Does ContentAdaption changes SMIL document's content |  Search
|
|
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ Archive through October 29, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| Sandeep Gulyani |
My Question is does NOWSMS gateway contentadaption process changes SMIL document's SRC tag, if there is any change in content type such as WAV to AMR. | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Yes, it does. If there is a SMIL component, changes in the audio type or image type will result in changes to the SMIL file references. Similarly, we do change any "cid:" references in a SMIL file to references by "content location", as content-id's are often lost when messages are routed to/from e-mail clients. -bn | |||
| Murali Mohan.K |
Hi, I just want to know which of the two, i.e. Content-ID and Content-Location, is better to use in a SMIL file for "src" references?. In some docs from nokia and ericsson, i have seen them specifying both the headers. I wonder why we need to identfiers, since "src" uses only one reference, i.e src="a.gif" for content-loc OR src = "cid:a.gif" for content-id. Is there any possibility of using both headers to refer to one component ?? Thanx in advance.. murali | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Murali, If you're creating SMIL, then I would recommend using Content-Location for the greatest portability. If you are receiving SMIL as a client, then you have to be prepared to handle either. I recommend setting Content-Location and Content-ID as the same value in any SMIL content that you generate ... it keeps life simple. -bn | |||
| Murali Mohan.K |
Hi Bryce, Thanx for the response. I would like to know the exact difference between content-id and content-location. Thanx murali | |||
| Bryce Norwood - NowSMS Support (Bryce) |
Murali, Take a look at RFC2045 and RFC2387. http://www.ietf.org/rfc/rfc2045.txt http://www.ietf.org/rfc/rfc2387.txt RFC2045 documents MIME itself, so that is a good starting point. RFC2387 documents the multipart/related MIME format, and goes into a bit more detail on issues specific to multipart/related content. If you recall, the format of an MMS message is multipart/related when a SMIL presentation exists in the message. The content type header in this case includes a "start" parameter pointing to the content-id of the message part that contains the SMIL data. (If there is no presentation, then the message is multipart/mixed.) I can't say that I've read through these specs word for word, so there may be some nuances that I have missed. -bn | |||
