Vjacheslav Chekushin wrote:
Just remark.
SX1 behavior _NOT_ conforms to wap specification, because besides general encoding there is well-known encoding for Accept header:
8.4.2.7 Accept field
The following rules are used to encode accept values.
Accept-value = Constrained-media | Accept-general-form
Accept-general-form = Value-length Media-range [Accept-parameters]
Media-range = (Well-known-media | Extension-Media) *(Parameter)
Accept-parameters = Q-token Q-value *(Accept-extension)
Accept-extension = Parameter
Constrained-media = Constrained-encoding
Well-known-media = Integer-value
; Both are encoded using values from Content Type Assignments table in Assigned Numbers
Q-token = <Octet 128> )
And we have: Accept-general-form => Value-length Media-range [Accept-parameters]
So value-length is 0 and Media-range (mandatory) is absent.
So Accept header must be either as string "Accept: ..." or "80 ..." and in the last case it _MUST_ be encoded as Accept-value.
ok, agreeing for the 'Accept-value = Constrained-media | _Accept-general-form_' value. _BUT_ what about _Constrained-media_?
If comes up to Extension-media where the reference BNF is used. IMO the Accept encoded byte 0x80 followed by a 0*TEXT (hence nothing), followed by a end-of-string 0x00 is allowed then.
Comments on this please.
Stipe
mailto:stolj_{at}_wapme.de ------------------------------------------------------------------- Wapme Systems AG
Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0 fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------
