| Additional header in bodypart |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through December 01, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
Hi, I would like to specify a proprietary header along with my content, i.e. something like, in a specific body part : << Content-Type: image/jpg Content-Transfer-Encoding: base64 Content-Location: Bicycle.jpg ProprietaryHeader: value ... >> It seems that the MMSC strips-off this unknown header (I'm using v5.5). Can you confirm that ? Is there a way to work-around this behavior ? Thanks in advance. Best Regards | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3067 Registered: 10-2002 |
Are you submitting via MM7? MM4? I'm sure that you're correct, and that we limit what headers we pass through. Can you tell me what you're using the proprietary header for? | |||
| Fred Unregistered guest |
Hi, Thank you for your answer. I've submitted via SMTP. Actually I'm focusing on OMA DRM v1 implementation / Separate Delivery, and would like to use the 'X-Oma-Drm-Separate-Delivery' header, as specified in the OMA spec. and the 3GPP MMS spec. I agree, it's not a proprietary header then if specified in a normative spec., but I meant by 'proprietary' : 'specific to a particular content type' (which is in this case application/vnd.oma.drm.content). Can you help ? Best Regards, Fred | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3070 Registered: 10-2002 |
Fred, That makes sense ... I can see where there is a need here. (I'd be more skeptical about adding support for arbitrary headers, but there is a clear requirement here.) It'll take a few days to week, but we should be able to accomodate this. -bn | |||
| Fred Unregistered guest |
Thank you for this quick answer. Does it mean you will fix the product to support this ? If so, when will it be available ? Thanks and best regards, Fred | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3125 Registered: 10-2002 |
Fred, Yes, we are planning to fix this. Unfortunately, it is a bit of a challenge as we do a lot of conversions to different formats. It is very easy to support this header when we are the MMSC, and we are receiving messages in MM7 or MM1 (EAIF) format. But it is a bit more of a challenge if we then have to route the message to another MMSC. Basically, we just have to test quite a few different permutations to make sure that we are always passing this header through. Perhaps you could help me clarify something though. As I read the DRM specifications, I am confused about something. As best as I can determine, the content type "application/vnd.oma.drm.content" is only used when DRM separate delivery is used. And the "X-Oma-Drm-Separate-Delivery" header is only used with this type of content. So it puzzles me why the header would be required at all. (Yes, I understand it is a hint for how much later to expect the rights message ... but the example in the specification is ridiculous. Generally the rights are going to be posted via SMS, and there will be some delay, but the delay is almost impossible to predict, so it is always going to be a wild guess.) Anyway, what I'm getting at here is that I'm wondering how we could support this header easily for the MMSCOMP format ... as if we are going to support it, I would like to see it supported through all interfaces. The MMSCOMP format is described here: http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_c ontent/Creating_MMS_Message_Files.htm I'm wondering if it just makes sense to automatically generate this header, with a value of "60" seconds whenever MMSCOMP processes an object of the type "application/vnd.oma.drm.content". Any thoughts? -bn | |||
| Fred Unregistered guest |
Bryce, You're correct, only one content type is applicable with this X-Oma-Drm-SD header (i.e. the DCF content type). You're also correct saying that the delay indicated by this header is generally a guess, indeed there is no way to garantee that the SMS will actually be received by the device in the estimated delay (although it gives at least an indication for the device that the rights object has been triggered). However, I'm not sure to follow you while speaking about MMSCOMP. Indeed, if this header is present, according to 3GPP [23.140] specification, it must be at the body part level only, so basically along with the DCF itself, e.g. : << Content-Type: application/vnd.oma.drm.content Content-Transfer-Encoding: base64 Content-Location: Bicycle.dcf X-Oma-Drm-Separate-Delivery: 15 [... DCF file base64 encoded ... ] >> If I understand correctly MMSCOMP, this only deals with 'global MMS', assembling several body parts and adding the MMS headers? Each body part is not built with this tool. My assumption is that the originator of the MMS composes the Message, specifying the X-Oma-Drm-SD and the value, and the MMSC shall neither strip-off this header, nor alter the value. The MMSC shall not make any additional task with regard to this particular content type, I think it's not his role. It's rather the role of a 'DRM component', whatever it is. Hope this clarifies. Thanks and Best Regards, Fred | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3163 Registered: 10-2002 |
Hi Fred, My reference to MMSCOMP was basically that if we supported this header, I wanted to have it supported across all areas of NowSMS. In MMSCOMP, we don't have a way to specify additional headers to be associated with individual body parts of the message. I think we've got a solution for this which will maintain the header across all of the interfaces now. We're not ready to put this release out for general downloads yet until it sees some more testing. But if you could send an e-mail message to nowsms@now.co.uk, referencing this issue, I will e-mail you an update that should do the trick. -bn | |||
