Re: [RFV] late request for voting/vetting for several stuff

Bruno Rodrigues wrote:
> 
> I should have asked for comments before, but I'm really work-free now
> and I'd like to implement stuff as fast as I can, even if there's
> momentary cvs versions with major bugs.
> 
> If you can, please test cvs versions as hardly as you can and report
> everything you find to this list so I can see if I did something wrong
> and be able to fix it right away.
> 
> These are the features I've implemented and after that, a list of stuff
> I'm about to fix/implement unless you complain very hard ;)
> 
> I'd like to ear your comments and/or any reason against them. It's still
> not too late to rollback anything.
> 
> (Here we go, by your request Stipe)

to be more precise: by consensus of the group ;)

> 2003.07.07 - header packing implemented
> I've implemented this feature to aggregate similar headers because some
> devices I have sends so many headers that if we send one header per
> value, I get "too many headers", if I aggregate them all in one header,
> I get "header too long".
> http_header_pack packs headers with 256 characters (defineable)

definetly +1. Even while we make a workarround for too tightly
confiured HTTP servers. We've seen these problems on various devices
too.

> 2003.07.13 - wbxml dynamic version byte and wap dynamic version byte
> I'm looking at device header sent and I'm setting wbxml version acordly.
> I'm looking at wml's externalid declaration and settings wbxml's wap
> version acordly. This was required because SE-T610 looks at them and
> would ignore some 1.3 tags if version was 1.1 - it won't respect
> <form type="multipart/form-data" for example

so this fixed the 'multipart/form-data' thing for SE?

(BTW, for all others reading, SE = SonyEricsson)

> 2003.07.13 - added wap deconverters to decode
> application/vnd.wap.multipart.form-data to multipart/form-data. working

+1

> 2003.07.13 - preliminary support to decode mms binary into text.
> deconverter is implemented, I'm just waiting for Stipe's commits for his
> mms code.

+1, it's coooooooooming. Let me have my hands on the configure/make
process and you will have a bunch of commits here. It's gonna be
anyway after 1.3.2 has been released.

> 2003.07.13 - preliminary suport for multipart/mixed to
> application/vnd.wap.multipart.mixed, on hold until I fix some more
> important stuff (and Stipe's mms encoder would also help me)
> 
> 2003.07.13 - kannel now tries to adapt xml/xhtml content's charset to
> the one supported by device. Kannel already adds other Accept-Charsets
> to request headers, so this looks like a needed feature to me (needs to
> be tested with other charsets beside utf8 and iso-8859-1)
> Note: Panasonic GAD87 devices (at least in Portugal) became very broken
> with this because they are really broken and announce that they only
> support utf-8 but they really only support iso-8859-1 - accented chars
> are totally mangled. I don't want to make exceptions in kannel and I've
> already complained to Panasonic.

+1, yep, good way.

> 2003.07.13 - removed "Version=0" parameter when sending cookies to
> external servers. This is not very explicit in specification but I
> haven't ever seen a client sending this parameter

+0, ok with me.

> 2003.07.14 - added http response 406 back to device if content type is
> not supported by it. (today I've fixed the */* problem). This was
> required for (at least) Nokia 7650

+1.

> 2003.07.18 - smsbox - mo-recode now tries to also recode to utf-8 if iso
> fails. for external servers, it's easier to process utf8 than ucs2/utf16
> (documented)

+0.

> 2003.07.19 - smsbox - dlr won't work at all if smsc-id is undefined -
> dlr_add and dlr_find just returns if no smsc-id. smsc-id required for
> dlr processing was documented

+1

> 2003.07.20 - removed smsc_at, renamed at2 to at; moved emi to emi_x25,
> removed internal emi_ip and renamed emi2 to emi, documented it

definetly +1.

> 2003.07.20 - broken smsbox compatibility to enable mclass=0..3,
> coding=0..2 and pid=0..255. This was already talked about and it's
> required to be able to set pid=0 and to be consistent with specification
> (it's dificult to explain to someone that for etsi's message class 0 you
> need to set kannel's mclass to 1)

yep, +1. Did you test all dependencies on this?!

> 2003.07.20 - added hplmn and auth-code support, although not yet
> implemented on smsc_emi (bug #54)

?? (have to check mantis)

> 2003.07.20 - maintained parameter consistency and always use urlencoding
> for udh and binary data in POST headers and in xml. I had several
> complains because common sense will make you send url-encode in http
> udh header and then you ask yourself why is it not working

??? (didn't get the point. too less coffee this morning? ;))

> 2003.07.21 - made wap cookies enable per default. Please complain about
> what is not working with them so I can fix it. So far, I know, and I'm
> working thowards it, that we should try to send cookies to device
> (bug 34), that cookies are not checked for domain, path and secure (bug
> 64), and that they might not work at all with connectionless wap.
> I need cookie support and I'd rather activate it and fix it.

+1, we have to work on passing the Cookies in WSP encoding to the
device.

> 2003.07.23 - added new url-map groups (deprecating map-url directives)
> to enable, for each url, an rewriten url, a query-string parameter to
> send msisdn, an header to send msisdn, an msisdn format and if kannel
> accepts cookies or not. This is required for Telcos to enable msisdn
> sending and cookie support only to who they want to.

should we have something like Apache mod_rewrite implemented here?

Yeah, that's the old "I'm the telco and I have the power *prune*"
story ;))

+1, anyway.

> 2003.07.23 - added proxy-authorization support to kannel. In wap
> architecture, kannel IS the proxy, so those values are to be processed
> by kannel and not by and external server (kannel was already removing
> that header before requesting). with user-map groups, you can define an
> user/pass to msisdn map to be used before requesting radius.
> As we (and most of the people) don't have access to radius packets, this
> is a simple and easy way to add device identification and enable kannel
> to send msisdn headers, simulating other products. Too bad that some
> devices (Nokia) doesn't have proxy auth parameters :((

that's an religious issue. Kannel is not and HTTP proxy in direct
terms. It is responsible for WSP <-> HTTP proxying.

Have to check this more deeply.

> Things in my to-do queue:
> finish what's left to finish in previous list
> finish whatever is marked as /* DAVI: .... */ in code
> finish mms decoding/encoding as soon as Stipe commits his code
> other stuff marked on bugs.kannel.org

ohhh, please addd this too:
* reformat all my commits to comply with CodingStyle rules *grrrrrr*
;) (I really hate those <tab>s from you ;)

Good work so far Bruno!

Stipe

[email protected]
-------------------------------------------------------------------
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [email protected]
Internet: http://www.wapme-systems.de
-------------------------------------------------------------------
wapme.net - wherever you are