From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 1/3] stkutil: display text attributes as html
Date: Thu, 01 Jul 2010 18:47:14 -0500 [thread overview]
Message-ID: <4C2D2902.5000801@gmail.com> (raw)
In-Reply-To: <20100701160543.255f66cf@kcaccard-MOBL3>
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
Hi Kristen,
On 07/01/2010 06:05 PM, Kristen Carlson Accardi wrote:
> On Thu, 01 Jul 2010 18:08:47 -0500
> Denis Kenzior <denkenz@gmail.com> wrote:
>
>> Hi Kristen,
>>
>>>>>> Then this code is incorrect, as it handles len 3 attrs only at the end
>>>>>> of the array. Also please note that SIM Toolkit Text Attributes are
>>>>>> always coded on 4 bytes (see 102.223 Section 8.72 for details). You
>>>>>> might want to assume 4 byte alignment or invent a data structure for
>>>>>> these attributes.
>>>>>
>>>>> I should have said that attrs_len does not always have to be a multiple
>>>>> of 4 -- it is allowed to only have 3 byte attrs as the last attribute,
>>>>> so the code is correct. However, since not all attributes are
>>>>> required to be of len 4, we can't just assume attrs_len is a multiple
>>>>> of 4.
>>>>>
>>>>
>>>> How do you figure this? From 23.040 Section 9.2.3.24.10.1.1 Text Formatting
>>>>
>>>> "Octet 4
>>>>
>>>> This Octet may be omitted by setting the IED length accordingly."
>>>
>>> This isn't the clearest language, so my interpretation of this is
>>> you may omit one byte if you set the length properly. Clearly
>>> the spec tell you that the byte is optional, so I think it would
>>> be wrong to assume that all are 4 bytes. Also, since obviously
>>> we can't support mixed 3 and 4 byte fields since we'd have no
>>> way to know if the next byte was the start of the next attribute,
>>> it's got to be at the end of the array.
>>
>> Actually it is not. Each Text attribute is put into an SMS header, with
>> the header having an IEI (Information Element Identifier), Length and
>> Data. See SMS_IEI_TEXT_FORMAT in smsutil.h
>>
>> Hence, when an EMS PDU is parsed, you know whether this is a 3 byte or a
>> 4 byte element.
>>
>> Regards,
>> -Denis
>
> The way this function is - we have no knowledge of the pdu.
> Are you wanting to change the arguments to this function to include
> an sms header? or a pdu? Or are you saying the caller is responsible
> for padding out the text attribute into a 4 byte attribute?
Correct, assume the caller will always give you quadruples. 3 byte
values can only happen in EMS, and those are wrapped in user headers.
It is not a single contiguous array. Some external entity will need to
appropriately format the text attribute array for your consumption in
this case.
Regards,
-Denis
next prev parent reply other threads:[~2010-07-01 23:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-29 11:22 [PATCH 0/3] html text attribute patches Kristen Carlson Accardi
2010-06-29 11:22 ` [PATCH 1/3] stkutil: display text attributes as html Kristen Carlson Accardi
2010-07-01 16:30 ` Denis Kenzior
2010-07-01 18:29 ` Kristen Carlson Accardi
2010-07-01 18:54 ` Denis Kenzior
2010-07-01 20:54 ` Kristen Carlson Accardi
2010-07-01 21:15 ` Denis Kenzior
2010-07-01 22:56 ` Kristen Carlson Accardi
2010-07-01 23:08 ` Denis Kenzior
2010-07-01 23:05 ` Kristen Carlson Accardi
2010-07-01 23:47 ` Denis Kenzior [this message]
2010-07-01 22:10 ` Andrzej Zaborowski
2010-07-01 22:35 ` Denis Kenzior
2010-07-01 22:47 ` Andrzej Zaborowski
2010-07-01 22:50 ` Denis Kenzior
2010-06-29 11:22 ` [PATCH 2/3] test-stkutil: add unit test for html text attributes Kristen Carlson Accardi
2010-06-29 11:22 ` [PATCH 3/3] test-stkutil: add html attribute test for Display Text tests Kristen Carlson Accardi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C2D2902.5000801@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.