URI Syntax Limitations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

URI Syntax Limitations

Manuel Urueña
Hello,

While studying the deployment of new protocols in Internet, I've found
some limitations to current URI syntax:

- Although URIs can include a port number, the transport protocol to be
used cannot be specified (i.e. UDP or TCP in DNS). Thus, each URI scheme
is bound to a single transport protocol. This limitation could hinder
the usage of newer protocols like SCTP in current applications (e.g.
HTTP over SCTP).

- Host identification is limited to plain IP addesses (no IPV6 scope id)
or DNS-like hostnames. Therefore, although each scheme could define an
alternative resolution mechanism for the "host" part, this limitation
could also hinder the deployment of newer Service Discovery (e.g. SLP)
or Load Balancing (e.g. Rserpool) protocols, that offer some kind of
alternative name-resolution mechanism.

Browsing the mailing list archive I've seen that some newer protocols
define some arguments in the query part (like "transport=SCTP") in their
URI formats in order to cope with the first issue.

However IMHO this mechanism could not be applied to all URI schemes
already defined, as the "query" part is optional, thus many schemes do
not allow any arguments.

Are there any proposed solutions to these issues?

Regards,
--Manuel Urueña


--
Manuel Uruen~a - Universidad Carlos III de Madrid
GPG FP: C20B 7F07 09E3 FB95 7AD9  D03A DA93 AA09 4EE2 675B
http://www.it.uc3m.es/netcom

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: URI Syntax Limitations

Roy T. Fielding

On Nov 9, 2005, at 4:38 AM, Manuel Urueña wrote:

> While studying the deployment of new protocols in Internet, I've found
> some limitations to current URI syntax:
>
> - Although URIs can include a port number, the transport protocol to be
> used cannot be specified (i.e. UDP or TCP in DNS). Thus, each URI
> scheme
> is bound to a single transport protocol. This limitation could hinder
> the usage of newer protocols like SCTP in current applications (e.g.
> HTTP over SCTP).

It isn't a limitation. Authorities are bound by transport protocol
as well, so there is no value in treating them as the same space.
It is simply a choice as to whether the junction is part of the
authority syntax or the scheme syntax.  Since URIs were deployed
long before anyone considered that question, the choice has
narrowed to different schemes.  In other words, just define
"http.sctp" and "http.udp" schemes, if so desired.

The technical advantage of them being different schemes is because
applications will need a different protocol module to resolve them.
Since well-designed URI applications use a dispatch-on-scheme
table for handlers, it is technically superior to place that info
in the scheme name instead of inside the authority component.

> - Host identification is limited to plain IP addesses (no IPV6 scope
> id)
> or DNS-like hostnames. Therefore, although each scheme could define an
> alternative resolution mechanism for the "host" part, this limitation
> could also hinder the deployment of newer Service Discovery (e.g. SLP)
> or Load Balancing (e.g. Rserpool) protocols, that offer some kind of
> alternative name-resolution mechanism.

No such limitation exists, so my guess is that you are assuming
something that isn't said in STD 66.

> Browsing the mailing list archive I've seen that some newer protocols
> define some arguments in the query part (like "transport=SCTP") in
> their
> URI formats in order to cope with the first issue.
>
> However IMHO this mechanism could not be applied to all URI schemes
> already defined, as the "query" part is optional, thus many schemes do
> not allow any arguments.

I don't know of any worthwhile schemes that have done something
as goofy as placing a transport protocol in the query part.
All such proposals in the past have been told to use the scheme
name, as in http/https. The only reason you don't see http.sctp
in the registry is because nobody has asked for it yet.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Reply | Threaded
Open this post in threaded view
|

Re: URI Syntax Limitations

Manuel Urueña
Comments inline


El mié, 09-11-2005 a las 15:50 -0800, Roy T. Fielding escribió:

> On Nov 9, 2005, at 4:38 AM, Manuel Urueña wrote:
>
> > While studying the deployment of new protocols in Internet, I've found
> > some limitations to current URI syntax:
> >
> > - Although URIs can include a port number, the transport protocol to be
> > used cannot be specified (i.e. UDP or TCP in DNS). Thus, each URI
> > scheme
> > is bound to a single transport protocol. This limitation could hinder
> > the usage of newer protocols like SCTP in current applications (e.g.
> > HTTP over SCTP).
>
> It isn't a limitation. Authorities are bound by transport protocol
> as well, so there is no value in treating them as the same space.
> It is simply a choice as to whether the junction is part of the
> authority syntax or the scheme syntax.  Since URIs were deployed
> long before anyone considered that question, the choice has
> narrowed to different schemes.  In other words, just define
> "http.sctp" and "http.udp" schemes, if so desired.
Yes http.sctp does work, however it seems harder to read than, let say
sctp.80 in the port section, albeit this could my personal taste, of
course.

Also, as the scheme part is parsed by each application, adding new
"fields" could be more complex (e.g. "http" = "http.tcp" = "http.dns" =
"http.dns.tcp" <> "http.rserpool" = "http.tcp.rserpool", ...).

> The technical advantage of them being different schemes is because
> applications will need a different protocol module to resolve them.

That's true in most cases, although in some migration scenarios the new
protocols try to emulate the previous API, thus the application can
maintain the same system calls.

For example, for one-to-one communication the SCTP socket API is exactly
the same tan the TCP one. It is only necessary to replace:

int socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

by

int socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP);
                                 ^^^^^^^^^^^^
> Since well-designed URI applications use a dispatch-on-scheme
> table for handlers, it is technically superior to place that info
> in the scheme name instead of inside the authority component.

Well, if the URI syntax would define a (optional) Transport ID part
inside the authority section the URI parser libraries could return the
token or to the application, and then employ a dispatch-on-transport
mechanism, or just return the appropriate IPPROTO_* value, thus the
application could easily change between TCP or SCTP on demand.

> > - Host identification is limited to plain IP addesses (no IPV6 scope
> > id)
> > or DNS-like hostnames. Therefore, although each scheme could define an
> > alternative resolution mechanism for the "host" part, this limitation
> > could also hinder the deployment of newer Service Discovery (e.g. SLP)
> > or Load Balancing (e.g. Rserpool) protocols, that offer some kind of
> > alternative name-resolution mechanism.
>
> No such limitation exists, so my guess is that you are assuming
> something that isn't said in STD 66.
Sorry, my mistake, RFC 3986 only says DNS is the most "common" registry
mechanism... I incorrectly assume it as mandatory because it is
widespread.

However, as each scheme is bound to a single registry mechanism, this
has some drawbacks, even if using an extended scheme like "http.dns".
Please let me elaborate a little more.

A possible problem comes from collapsing an entire name resolving system
within a single token. For example http.dns://www.example.com could mean
"ask for the AAAA or A Resource Record of www.example.com". But then DNS
service discovery cannot be employed in URIs because
"http.dns://_www._tcp.example.com" would not query the SRV RR, unless a
new "http.dns_srv" scheme is added, but there would be too many schemes
to cover all the possible variations.

Moreover, an advantage of including a name-resolving id in the registry
part is that it could be transparently processed by the OS, as basically
applications should not bother what name resolving mechanism is
employed, as far as it gets a valid IP address and the target port
number.

On the other hand, with a simple scheme-handler mechanism, each
application should deal with different service discovery libraries, and
be modified to support each new service discovery mechanism. If the
registry id were resolved by the OS, it would be necessary just to add a
plugin or patch it and all the applications could benefit from the
newest service discovery protocol.


> > Browsing the mailing list archive I've seen that some newer protocols
> > define some arguments in the query part (like "transport=SCTP") in
> > their
> > URI formats in order to cope with the first issue.
> >
> > However IMHO this mechanism could not be applied to all URI schemes
> > already defined, as the "query" part is optional, thus many schemes do
> > not allow any arguments.
>
> I don't know of any worthwhile schemes that have done something
> as goofy as placing a transport protocol in the query part.
> All such proposals in the past have been told to use the scheme
> name, as in http/https. The only reason you don't see http.sctp
> in the registry is because nobody has asked for it yet.
Best regards,
--Manuel

--
Manuel Uruen~a - Universidad Carlos III de Madrid
GPG FP: C20B 7F07 09E3 FB95 7AD9  D03A DA93 AA09 4EE2 675B
http://www.it.uc3m.es/netcom

smime.p7s (2K) Download Attachment