| DRM Messages and Boundary parameter |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through December 19, 2005 ⬆ |
◄ ► |
| Author | Message | ||||
| Fred Unregistered guest |
Hi, I would like to send Forward Lock objects via MMS, submitted to MMSC via the SMTP interface. The multipart will look like : Content-Type: multipart/related; boundary="b1" --b1 Content-Type: application/vnd.oma.drm.message ; boundary="b2" Content-Transfer-Encoding: base64 Content-Location: Bicycle.dm [...] My question is : how this b2 boundary will be handled by NowMMS, i.e. what kind of MM1 message will I get? According to 3GPP & OMA MMS specifications, this boundary parameter must not be altered, i.e. the content type must still be, strictly in text format : 'Content-Type: application/vnd.oma.drm.message ; boundary="b2" ' Does the product support this ? Thanks in advance for your help. Best Regards | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3826 Registered: 10-2002 |
Fred, This should work in v5.51. (I'm not sure about earlier releases.) We will encode the boundary into the MM1 message envelope. The best thing to do is try it, and if you have any problems, we'll take a look at the debug logs. -bn | ||||
| Anonymous |
Hi, I'm trying to use OMA DRM Forward Lock, and this is the file obtained by the MMSC (transmitted through the SMTP interface):
It does not look exactly compliant with 3gpp specification, in terms of : 1/ content type and boundary being unaltered (the ';' at least between "Content-Type: application/vnd.oma.drm.message" and "boundary=... " has been stripped off 2/ some headers inside this multipart have been modified, actually binary-encoded . e.g. a Content-Location header. 3GPP specification [23.140] section 7.1.15 seem to mention that this shouldn't happen. Is my understanding correct? Could you please comment ? Thanks in advance, BR, Fred | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3994 Registered: 10-2002 |
I'm sorry Fred, but you've lost me. I don't understand your question. You've posted a binary format MM1 message here. And you're quoting from the 3GPP specification ... where 3GPP only defines MM1 in an abstract fashion. (OMA defines the binary MM1 format.) 1.) I can't see your original header, so I can't comment on whether or not it has been altered or not. But in the binary message, I can see that the content-type header does include a boundary parameter. If you are expecting to see the content type, including parameters, encoded as text, without alteration ... that would not be correct encoding. The binary MMS format uses MMS encapsulation, where the message content is encoded using WSP multipart binary encoding. In this encoding, there is an encoding format defined for the content-type header. 2.) Yes. You are looking at a file that is encoded using the MMS Encapsulation format. The only headers that are not encoded are the ones that are part of the actual "application/vnd.oma.drm.message" content. My suggestion would be to look at one of these files when you have not encoded anything with forward lock. You will see that all of the headers are binary encoded. You only end up with a mix of binary and text when you use forward lock because some of the headers are part of the actual forward lock content. It is also possible that I have completely misunderstood your questions, so if I have, please try to rephrase and clarify for me. -bn | ||||
| Fred Unregistered guest |
Hi Bryce, Sorry if I were unclear. My point was just, to sum up, that, as the original content type of FL files is 'application/vnd.oma.drm.message ; boundary = "xxx"', I would expect to find the whole content type (including the boundary info) in the MM1 message. That's what I understand by the following statement (picked from 3GPP spec, section 7.1.15.3.1 ): "The MMS Relay/Server shall not alter or strip-off any part of the ‘DRM Message’ header (e.g. the Boundary parameter declaration). " I hope it's more clear now. Any thoughts? Thanks in advance, BR, Fred | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4029 Registered: 10-2002 |
Hi Fred, I can see where you are coming from with that. I guess it just helps me to think of the 3GPP specs as being more of a "requirements" document and being "abstract" in its definition of MM1. For example, the 3GPP spec defines the transactions, and the fields, but it doesn't define the format. In this particular case, the content type has to be encoded into an MM1 M-Send.req or M-Retrieve.conf PDU. The OMA MMS Encapsulation Specification (which defines the raw format of the MM1 PDUs), specifies that the Content-type should be encoded using the Content-type-value format of WAP WSP 8.4.2.24. In that definition, parameters are separated from the raw MIME type. So if you look at the Media-type definition, you'll see that you first have the MIME type (e.g., application/vnd.oma.drm.message), followed by the parameters. The MIME type can be encoded as a short code (well-known-media) or text name (extension-media). There are also short codes for different parameter names defined in Table 38, but "boundary" is not one of them, which is why it appears as text. So basically, taking: application/vnd.oma.drm.message ; boundary = "xxx" And literally including it in the content-type field, would violate WSP encoding. Technically, the content-type field is not being altered in this process, it is just being translated from HTTP to WSP. At least that's my take on it. I could very possibly be wrong. I am assuming that when the WSP spec says that "Extension Media" is a text string to encode a media value, that "media value" refers only to the "media type" and "media subtype" (a.k.a., "MIME type") as defined in the MIME RFCs. The MIME RFCs talk about there being parameter modifiers ... which I assume are the parameters referred to in the WSP spec. I haven't checked to see if any of the updated DRM specs get any clearer on this issue, but they might. In any event, I'd take the 3GPP statement as a "requirement" where the intent is that the content type header needs to be preserved in its entirety. The requirement is that the content of the parameter not be altered or stripped off. And in this case its not, it is just a requirement that the encoding at the MM1 layer uses a WSP defined binary header encoding instead of a textual encoding. -bn | ||||
| newtomms Unregistered guest |
for mmbox feature wat will be the content type and if it is multipart/mixed pls provide me the link of how to encode it | ||||
Test Sample with Boundary
