I-Mode

otron

The Corinthian wrote:

You would think so given the greater bandwidth afforded by GPRS and 3G, but apparently not.

Im not sure what part of the spec you are referring to, the doc is 24 pages long.
Maybe you are referring to the w-http support for (gzip AFAIR) content compression? This is indeed done by the gateway but is different to byte-encoding.. in the WAP1 sense anyway. If that's a pedantic point, fair enough.

The Corinthian wrote:

Last time I read a tech spec from NTT DoCoMo, it did.

What exactly are you referring to? CHTML being byte encoded? Can you refer/lnk to this DoCoMo spec?

The Corinthian

otron wrote:

Maybe you are referring to the w-http support for (gzip AFAIR) content compression? This is indeed done by the gateway but is different to byte-encoding.. in the WAP1 sense anyway. If that's a pedantic point, fair enough.

Of course I was referring to content compression - what other type of byte encoding do you think we were discussing?

What exactly are you referring to? CHTML being byte encoded? Can you refer/lnk to this DoCoMo spec?

Sorry, can’t. It was an offline document.

otron

The Corinthian wrote:

Of course I was referring to content compression - what other type of byte encoding do you think we were discussing?

Well, when using the term "byte encoding" in the context of WAP, I tend to think of the encoding used in the headers of the WSP layer (Appendix A&B of the WSP Spec). Also, I believe that it is possible to further encode the actual WML page, replacing WML tags with byte values.

To me, this is byte encoding, and HTTP content compression is HTTP content compression. Again, if you see that as pedantic then fair enough.

The Corinthian wrote:

Sorry, can’t. It was an offline document.

I guess you mean (what I would call) content compression here also? Given that i-mode uses w-HTTP then that makes sense.

northowl

w-HTTP is just basic regular HTTP. Any wap2 recommendations are minor, mostly optional, standard RFC's. Most of them anyway are implemented on fixed line infra as they help there too.

WAP2 "gateways" are nothing more than HTTP proxies with fancy names.

WAP2 is Web1. There is no difference here lads, so ye are just splitting hairs talking about 'byte compression' and other red herrings.

The Corinthian

otron wrote:

Well, when using the term "byte encoding" in the context of WAP, I tend to think of the encoding used in the headers of the WSP layer (Appendix A&B of the WSP Spec). Also, I believe that it is possible to further encode the actual WML page, replacing WML tags with byte values.

To me, this is byte encoding, and HTTP content compression is HTTP content compression. Again, if you see that as pedantic then fair enough.

The byte encoding of WML content, using WBXML, is for the compression of WML content in a binary format. It's not all that pedantic.

northowl wrote:

WAP2 "gateways" are nothing more than HTTP proxies with fancy names.

And very high price tags. Funny how half the OMA produces them.

Slice

O2 are said to be launching i-Mode enabled handsets tomorrow with the biggest marketing spend since they rebranded from Digifone

otron

Hmmm .. Northowl - just signed up to join in this thread eh?

northowl wrote:

w-HTTP is just basic regular HTTP. Any wap2 recommendations are minor, mostly optional, standard RFC's. Most of them anyway are implemented on fixed line infra as they help there too.

Indeed. Any protocol related benefits of having a WAP2 proxy between the handset and the internet/content sites would mainly come from w-TCP rather then w-HTTP.

The implementation of the large inital window size, and the fact that the window doesn?t shrink back to 1 x MSS when a packet is lost (etc) would help download rates quite a bit more then any of the minor modifications in w-HTTP.

You are, of course, correct that these TCP features (as that?s all they are) could be implemented by a web server but that would be hit and miss, and far from universally supported.

For the record I?m not entirely convinced as to the level of improvement from using w-TCP and w-HTTP either.

northowl wrote:

WAP2 "gateways" are nothing more than HTTP proxies with fancy names.

There is definitely less of a place for a gateway in WAP2 alright. It's obvious that it would be possible to browse WAP sites without using one, over the operator?s internet APN. The only problems (apart from a possiblethroughput degradation) would be when it came to sites that normally receive the users phone number from the WAP-GW. The biggest example of this would be the operators MMSC.

How much that bothers someone is a matter for them to decide

MiCr0

The Corinthian wrote:

And very high price tags. Funny how half the OMA produces them.

We've got to sell something

wap proxys also handle charging&stats/access control/binary encoding/data push/the list goes on

The Corinthian

MiCr0 wrote:

wap proxys also handle charging&stats/access control/binary encoding/data push/the list goes on

Shussh! Otron will accuse you of pedantry

otron

The Corinthian wrote:

Shussh! Otron will accuse you of pedantry

Ah now here!

I was actually saying that if you thought what I was saying was pedantic then thats cool - didn't want to be seen to be pedantic myself!

Anyway, what was said about the other functions of the WAP-GW are true indeed. If they are of use to the operator then the role of the WAP-GW indeed becomes more important.

MiCr0

i work in wap gateways - and they are very big business
large system's can have 1500+ transactions per second on them
which is a lot of wap

they are also used for mms and video streaming to terminals
they also are used for information sharing between operators and website owners - for charging etc