The differences I mentioned are just the tip of the iceberg. Another example: the RFC definition for URI permits for every scheme to define their own character escape sequence for special and non ascii-characters. Guess what: sip allows reserved characters in the user field : sip:+1-212-555-1212:[email protected];user=phone. Another one? sip:alice;[email protected] is allowed and means user="alice;day=tuesday". (both from http://tools.ietf.org/html/rfc3261#section-19.1.23) An "extra" field is not going to be enough to get around these differences I'm afraid. Ludo
-----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de ik Envoyé : mercredi 18 mai 2011 17:03 À : FPC-Pascal users discussions Objet : Re: RE : [fpc-pascal] Re: URIParser On Wed, May 18, 2011 at 17:56, <[email protected]> wrote: On Wed, 18 May 2011, Ludo Brands wrote: Problem is that the RFC definition for the URI doesn't specify the individual protocol scheme. So every protocol can specify it's own stuff. Take the general sip URI: sip:user:password@host:port;uri-parameters?headers. User can be a telephone number with folowing definition: global-phone-number = "+" base-phone-number [isdn-subaddress] [post-dial] *(area-specifier / service-provider / future-extension) Or local-phone-number = 1*(phonedigit / dtmf-digit / pause-character) [isdn-subaddress] [post-dial] area-specifier *(area-specifier / service-provider / future-extension) This definitely will require custom processing. Also both uri-parameters and headers are name=value pairs. The first are separated by ";" and the second by "&"... I'm afraid a universal URI decoder isn't possible. Great. In that case I just declare that URIParser will only work for ftp and http protocols :-) I think it is possible. You can also add another field to the record of "Extra data" and allow others to parse it. the headers are like the HTTP URI (even the encoding of it is the same), and the params are like the HTTP Post more or less but divided by a semicolon. But I can work with parsing it myself imho, because that part is either starting with question mark or by semicolon. Michael. Ido _______________________________________________ fpc-pascal maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________ fpc-pascal maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
