Hello,

I have tried to use the URIParser on a structure like so:

;name=test?header=something

That's the most complicated SIP URI according to the RFC (3261).

But the record was able to just return to me the protocol (sip) and nothing else.
Does the unit implement it according to the URI RFC ? if so, what version of that (2396 or 3986) ?

Thanks,

Ido

LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il

I've created a more simple example:

program uri_test;
uses URIParser;
var
  URI : TURI;
begin
  URI := ParseURI('');
  writeln('URI:');
  writeln(#9'Protocol: ', URI.Protocol);
  writeln(#9'Username: ', URI.Username);
  writeln(#9'Password: ', URI.Password);
  writeln(#9'Host: ', URI.Host);
  writeln(#9'Port: ', URI.Port);
  writeln(#9'Path: ', URI.Path);
  writeln(#9'Document: ', URI.Document);
  writeln(#9'Params: ', URI.Params);
  writeln(#9'Bookmark: ', URI.Bookmark);
  writeln(#9'HasAuthority: ', URI.HasAuthority);
end.

The output is:
URI:
Protocol: sip
Username:
Password:
Host:
Port: 0
Path:
Document:
Params:
Bookmark:
HasAuthority: FALSE

Ido

You don't specify the protocol.

a URI starts always with "protocol://"

so

The URIParser unit expects the protocol to be in place.

Michael.

The problem is that the SIP URI (
http://tools.ietf.org/html/rfc3261#section-19.1 and http://tools.ietf.org/html/rfc3261#section-19.1.1) are more like the mailto: URI then the HTTP URI.

RFC 3986 <http://tools.ietf.org/html/rfc3986> does talk about such structure of URI as well.

Thanks,

Ido

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

> a URI starts always with "protocol://"

RFC 2396 (http://tools.ietf.org/html/rfc2396 ) specifies that an URI has to start with the protocol and a colon. The // depends on the protocol scheme. Valid URI's are for example or
news:comp.infosystems.www.servers.unix. The SIP URI is ;uri-parameters?headers and
;uri-parameters?headers for secure sip
(http://tools.ietf.org/html/rfc3261#page-148).

Ludo

In our previous episode, said:

The second is not an uri ?

Protocol is missing from the last one = not an URI. A protocol is asumed. Browsers assume http:, mailers mailto:, telnet assumes telnet:, etc

Ludo

Hmmm.

How can code distinguish between

and

?

Michael.

It is, but as far as I understand, you can not have a password without a user according to RFC3986 <http://tools.ietf.org/html/rfc3986#section-3.2>

Ido

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

sip is the protocol, mysecrect is the user name

according to the RFC is the proper way to have
1. Protocol
2. Empty user name
3. Password
4. Domain

Michael.

Ido

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

It should assume that sip is a protocol, like it does now.

I think that:

  URI := ParseURI('');

Should output this:

Protocol: sip
Username: bob
Password:
Host: example.com
Port: 0
Path:
Document:
Params:
Bookmark:
HasAuthority: FALSE

So, how to distinguish between the two ?

Is "sip" the protocol or the user name for a HTTP address ?

Michael.

I will check the implementation.

As far as I know, it was never meant to be RFC compliant, but we can change that of course.

Michael.

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:
;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.

Ludo

Great.
In that case I just declare that URIParser will only work for ftp and http protocols :-)

Michael.

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 - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

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 : ;user=phone. Another one?
sip:alice; 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

Great. In that case I just declare that URIParser will only work for ftp and http protocols :-)

What about file protocols like the 'text/uri-list' mime type? Such as what X11's XDND uses when you drag and drop from a local application window to a remote application window? In such cases one should supply the username and password with the origin host. Or like Qt4 DND and newer Windows DND applications uses.

eg: text/url-list mime type

I presume (though that always tends to be a bad thing) that because text/uri-list [as in my example above] should be ok with the FPC URIParser because it has the protocol 'file://' in the front - so authority info shouldn't be a problem? After all, file:// is pretty much identical to ftp:// URI syntax.

After a lot of careful investigation and mostly reading, I think that you can not really create a general purpose URI parser. It seems though that the FPC implementation is a *URL* and not a full URI parser, and I think it's better to document about it further. For example there are no URN support at all and it works only for specific type of URL that are mostly common, like the example you placed here.

Ido

LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il