| Forward-lock |  Search
|
|
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ Archive through March 23, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| newbie |
Acoording to section 5.2 (page 10) and B.1 (page 19) of "OMA-Download-DRM-v1_0-20020905-C.PDF", the forward-lock is specificed by Content-type: application/vnd.oma.drm.message; What I would like to know is the location of the content-type. Is the content-type specified in WSP header or MMS header? | |||
| Bryce Norwood - NowSMS Support (Bryce) |
I'll be honest, I'm just in the process of getting a handle on the OMA DRM specs myself. We're looking to implement a lot of DRM features into the Now SMS/MMS Gateway. The problem at present is that the specs are good for getting familiarity with the concepts, but until you see it in action on a phone, you're in the dark. I've seen that recent firmware versions of the T68i support the "application/vnd.oma.drm.message" MIME type, but according to UA Profile information, it is supported only in the WAP browser, and not in the MMS client. How the content type is specified would depend on how it is used (and how devices support it under MMS). What remains to be seen in practice is how this gets implemented by MMS client implementations. For a WAP browser implementation, it is simple ... like the example in B.1 of the spec that you referenced ... if you have a piece of content that you want to protect, instead of returning the content directly, you would return the content with an OMA DRM wrapper. The MIME type "application/vnd.oma.drm.message" would be specified as the content type for that object, and would be in the HTTP header (translated by a WAP gateway into the WSP header). Where it gets more complicated is with MMS. Can the DRM apply to the entire MMS message, or just to individual media objects within the MMS message? If it only applies to individual media objects, then the content-type in the MMS header remains "application/vnd.wap.multipart.related" or "application/vnd.wap.multipart.mixed", and the individual content objects inside of the multipart message would have a DRM wrapper around them. In this case, you would encode the OMA DRM content type in the WSP multipart header. If it applies to the MMS message as a whole, then I would assume that the content type in the MMS header would change from one of the multipart types to "application/vnd.oma.drm.message" ... and the actual MMS message would be wrapped in the OMA DRM wrapper. I'm curious to see an MMS client with DRM support to see which approach is implemented, or if both are implemented. At first thought, having forward lock against the MMS message as a whole would be preferable ... as long as the forward lock is inherited by objects within the MMS message. I'm curious to hear if anyone has any experience in this area yet with different client implementations. Which other phones have some DRM support in them? -bn | |||
| mark |
gfggfdgdfsgsgfsdg  | |||
| Bryce Norwood - NowSMS Support |
FWIW, since this message has popped back up to the top of the list, it seems that using DRM to forward-lock individual message components, as opposed to the whole message is the way that things are going. It would be nice to be able to just forward lock the message, and have that setting inherited by the included objects ... but you'll want to forward lock the objects indivdually. | |||
| Gary Chapman |
Hi Bryce, In Ericsson's MMS Developers Guidelines R6A.pdf they talk about application/vnd.sem.mms.protected on page 18. I was wondering what your take on this is. Is that particular WSP type a proprietary Sony-Ericsson thingie? And do you have any idea what is meant by "The SMIL reference must be on the inner content type where the content location header is recommended to be used..."? Gary | |||
| Bryce Norwood - NowSMS Support |
Hi Gary, That type is definitely SonyEricsson specific ("sem" in the MIME type is an ancronym for "SonyEricsson Mobile"). So you won't see this implemented in any non-SonyEricsson mobile devices. OMA forward lock is starting to be implemented in more devices. I never spent a lot of time trying to understand the SonyEricsson approach. I tried a few simple tests, but after an hour and a half, gave up. The specification leaves a lot to be desired, but now that I re-read it, I think I might understand it better. You put an "application/vnd.sem.mms.protected" wrapper around an individual piece of content that you want to protect (such as an image). The MIME type for that part of the content becomes "application/vnd.sem.mms.protected" instead of the original MIME type. The content of the "application/vnd.sem.mms.protected" part of the message is actually encoded as a WSP multipart entity ... even though there is only one object in the multipart entity. It would have been clearer to me had they stated that in the document. I originally couldn't make sense of it. The part that you're asking about makes more sense when I look at it now as well. It means that when your SMIL file makes reference to a protected object, the name that is referenced would correspond to the content-location that is embedded inside of the protected object. So to protect an object named image.gif, you encapsulate it into this "application/vnd.sem.mms.protected" object type, and that protected object itself takes on a new name, like image.gif.semmms. But if you reference the object in SMIL, your reference is to image.gif inside of the protected object, not to the protected object itself. As I was actually able to understand the spec after reading it again, I went ahead and wrote a little utility to create an "application/vnd.sem.mms.protected" object. SEMPROTECT takes two command line parameters, the filename to create a protected object from, and the MIME type of the object. (Example: SEMPROTECT image.gif image/gif) The output protected object is the name of the input object, plus an extension of ".semmms". (Example, input name image.gif gives output file image.gif.semmms.) The output file is in the "application/vnd.sem.mms.protected" format, and can be included in an MMS message. Only a SonyEricsson phone is going to understand this piece if it is included in an MMS message. If you want to be able to send this format via the Now SMS/MMS Gateway, then you need to update the MMSCTYPE.INI file. Under the [MMS Content Types] section, add: application/vnd.sem.mms.protected=.semmms Under the [Extensions] section, add: .semmms=application/vnd.sem.mms.protected You can then use the "Send MMS Message" function in NowSMS, and include this is a content component of an MMS message. If you want to use MMSCOMP to create a binary MMS message file that included this content type, MMSCOMP also consults MMSCTYPE.INI for the content type assignment (it also consults the Windows registry, HKEY_CLASSES_ROOT\.extension, so you could also add the MIME type for .semmms to the registry). I've uploaded SEMPROTECT as http://www.nowsms.com/download/semprotect.zip. Now, I just have to find the time to do the same thing for OMA Forward lock. -bn | |||
| Josh Woolever |
Bryce, Have you gotten OMA DRM forward-locking to work through EAIF. I am getting return status 400 from the MMSC when I attempt to do OMA wrapping of content. Cheers, Josh Woolever | |||
| Bryce Norwood - NowSMS Support |
Josh, Are you using EAIF to connect to an actual Nokia MMSC, or the simulator? How are you applying the forward lock wrapper? In my earlier post on this thread (from back in April), it mentions a question about how the OMA forward lock would be applied to an MMS message ... whether it would be applied to the MMS message as a whole, or whether individual content pieces of the message would have a forward lock wrapper. At this point, I don't think there's a question there. The forward lock wrapper would be around individual pieces of content. I still need to find the time to put together a simple utility for this however. | |||
| Josh Woolever Unregistered guest |
It's connecting to an actual Nokia MMSC. The wrapper is being applied to single pieces of content using content-type=application/vnd.oma.drm.message;boundary="blahblah" The content itself then is the drm-wrapped piece (an image, say) with that boundary and what not. It worked when we used true Multipart MIME messages where the OMA content would just be an embedded piece. But with the binary format it doesn't seem to like this as much. We're now using version 1.2 of the Nokia Java library because supposedly it's better at working with drm. Thanks, Josh | |||
| Gino Comino Unregistered guest |
Sorry to disturb you, I am working for a thesis about DRM ...about forward_lock-OMA DRM phase 1.0... I have 3 questions: 1)what type of content (images,animations,games,mms) can be forward-locked in a OMA compliant cell phone? 2)what happens if I send a forward-locked content to a cell phone not oma-compliant(which doesn't support forward locking)? 3)what are the specifications a content should have to implement the forward-lock feature? Is there a field, a flag added in it and interpreted by the cell phone? 4)which are the macro-operations of a cell phone to rightly interpret a fow-locked content when it receives one? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1138 Registered: 10-2002 |
Gino, FYI, there's an interesting discussion about forward-lock over in this thread: http://support.nowsms.com/discus/messages/1/1011.html To your questinos ... 1.) Any type of content can theoretically be forward-locked. A forward-lock is just a wrapper around content. 2.) The content is not understood and the phone does not know how to interpret the content. 3.) The thread that I referenced above includes some examples as people worked through the process of implementing it. If you have not already visited the Open Mobile Alliance site (http://www.openmobilealliance.org) to download the OMA DRM specifications, then you should, as it is described in those specs. For simple forward-lock, it is a simple MIME wrapper around existing content. 4.) I'm afraid you're talking university-speak, and as a working bloke, that is not my native language.  Basically, OMA DRM content is content with a MIME type of "application/vnd.oma.drm.message" ... so when an application receives content of that format, it interprets it according to the definition of that MIME type, which can be found in the OMA DRM specifications. | |||
| Paul Sabertini Unregistered guest |
Bryce, Are you able to tell us anything about the new DRM features you're looking to put into NowSMS? Other than applying the forward lock flag, what other features can really be supported within MMS at this stage? Thanks, Paul. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1165 Registered: 10-2002 |
Paul, At this point, I think forward-lock is the only thing that is practical ... especially with regard to MMS. The more sophisticated DRM features will be more applicable to applications (in particular Java or Symbian applications). The compelling idea here is that you could offer time limited trials of an application, or limit the number of times that an application can be executed. A special DRM message over WAP push could be used to extend this time limit after a purchase ... or it could be handled on a subscription basis where the extension is automatically sent out every month. I don't see this capability as being as important to MMS, because I think the main concern with MMS is just limiting re-distribution (forward-lock). But applications (which are better delivered via the browser and/or WAP push) have more sophisticated requirements. I'm not sure exactly how we're going to implement this in NowSMS .... but I expect we will at least offer some support for simplifying the encoding of the rights documents. -bn | |||
| Madhav66 Unregistered guest |
Hi Bryce, This was with reference to the Post by Gary Chapman. "In Ericsson's MMS Developers Guidelines R6A.pdf they talk about application/vnd.sem.mms.protected on page 18. I was wondering what your take on this is. Is that particular WSP type a proprietary Sony-Ericsson thingie? And do you have any idea what is meant by "The SMIL reference must be on the inner content type where the content location header is recommended to be used..."? " if for SOnyEricsson's semprotected the smil reference must be on the inner content type's content location header,what happens in the case of the OMA DRm forward lock application/vnd.oma.drm.message. In this case, the Smil reference should be on the application/vnd.oma.drm.message's content-location or there will a separate content-location for the wrapped image and smil refers to that? Logically i guess it should be on the application/vnd.oma.drm.message's content-location as the wrapped image may not be specfied a Content-location in its header as the OMA DMR spec doesnt specify Content-Location as Mandatory for Forwardlock wrapped object.I would like you thoughts/comments on this please? | |||
| Madhav66 Unregistered guest |
Hi Bryce, Can you please show an example of a full MMS WSP encoded OMA DRM forward-lock content type (application/vnd.oma.drm.message )in the WSP multipart header which also contains the mime-boundary PARAMETER and original content? It will follow a Content-General Form as WSP230 spec since it contains the Parameter definition(Boundary), right?Also,in MMS WSP encoding,is boundary parameter compulsory? | |||
