convert_string + librpc/ndr (via openchange) == fail

[Andrew Bartlett]

On Tue, 2011-05-17 at 10:32 +0200, sean finney wrote:
> Hi Stefan,
> 
> On Tue, May 17, 2011 at 09:32:01AM +0200, Stefan (metze) Metzmacher wrote:
> > >> If you know the character set globally, then setting the dos charset
> > >> will help, but I'm guessing this isn't as simple as that.  As we have
> > >> the iconv handle code (and tests using the handles), I think the correct
> > >> fix is to reinstate that onto the ndr structures, but in an optional way
> > >> (understanding the limitations around enclosed structures etc).
> > > 
> > > Like I said above, this isn't a global setting, it can different between
> > > different MAPI items depending on the configuration of the senders, AFAICT.
> > 
> > Then using uint8_t array seems to be the only option.
> > 
> > Or the code page also encoded somewhere in the request?
> 
> The MAPI item has a number of properties which define the codepage to
> be used for the property in question (this is all AFAICT, from digging
> in the code and reading the MS specs).
> 
> Example:
> 
> A message has the subject stored in a property PR_SUBJECT/PidLidSubject.  The
> codepage of this property is determined by another property, 
> PR_MESSAGE_CODEPAGE/PidTagMessageCodepage.  Other properties may use the
> latter as well, and some specific properties have their own (i.e. the message
> body has a dedicated property).  Additionally, there's some fall-back logic
> in the spec that says first to try this codepage, and then fall back to the
> folder-specified codepage (yet another property), and then the profile's or
> server's codepage (i think, and these would also be additional props).
> 
> So for a client that wants to send a batch request containing a list of
> different properties etc, this could be a bit of a chicken and egg scenario,
> or at least would involve a bit of extra convoluted logic to split up
> the batch of requests into several smaller batches.
> 
> And ultimately, since we're only talking about 8-bit null terminated strings,
> I don't see what's wrong with just passing that along to the caller, and allow
> them to handle it as they see fit (they may, for example, internally convert
> them to unicode before displaying them, allowing the client to reply in
> unicode).  If ndr_pull_string isn't the right function for that (which it
> sounds like it isn't), I guess there'd need to be an addition to the API and
> any code templating tools like pidl to allow pulling a null-terminated
> uint8 buffer.

It seems pretty clear we need an 8BIT flag or new string type.  I can't
see a good way that PIDL would be able to handle the string conversion
here, so as you suggest, you will need to code them manually on the
OpenChange side of things.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org