Re: DDDS / can you do sample full path ? (Fwd)

Just to supplement the lighting talk of yesterday with some technical 

Below we walk through DDDS (rfc3401-3405) with the URL:

A-Priori rule valid for all URIs (and URLs are a subset of URI's)
(chicken-egg solution - [4])

	s/^([^:]+)/\1/i;			[1]

which is hardcoded in the applications URI parser. Then: =~ s/^([^:]+)/\1/i;



Then look up 'http' in the well known domain (another chicken-egg
hardcoded thing - [6]):

	dig -t NAPTR

For the HTTP uri scheme.

	$ 	dig -t NAPTR
	...          21600   IN
		NAPTR   0 0 "" "" "!^http://([^:/?#]*).*$!\\1!i" .

So what we get back is an NAPTR [5] record with 5 values:

	value	meaning
1	0		Order - if there are multiple NAPTR records
			returned; this is the order of them.
2	0		Preference - preference within an order block
3	""		Flags; several are possible and generally
			they denote a terminal rule (see below).
4	""		Services: list of protocols and services
			supported by the end point (i.e. when it
			is a terminal rule - see below).
5	...		Regular expression
6	...		Replacement [2]

So we have a new regex:


Now apply this again to our url: =~ 
"!^http://([^:/?#]*).*$!\\1!i .

results in

Note that this was the last central/standards defined step;
everything from here is totally fqdn manager specific (i.e.
to who-ever manages

Now continue our DDDS loop (which is NOT recursive):

	dig -t NAPTR

And we get     1800    IN
		NAPTR   100 20 "" "" "!^http://([^:/?#]*).*$!!i" .
		NAPTR   100 10 "" "" 
"!^http://foaf.([^:/?#]*).*$!!i" .

Again we apply the regexes to the URL, in the right order (ordered by
order first and by pref (second field) second).

order 100, pref 10 
no match. Ok, next one.

order 100, pref 20 =~ 

and we get

So what has happened here is that we are routing the request to the 
right place;
as some URI's on our FOAF server are special cases; whereas most of them
go to the server Bali.

Then, you've guessed it, we do an other lookup

	dig -t NAPTR

and get back: 1800 IN
		NAPTR   100 10 "u" "http+I2L" 
"!^http://([^:/?#]*)(.*)$!http://\\1/\\2!i" .
		NAPTR   100 10 "a" "z3950+I2C" 
"!^http://([^:/?#]*)(.*)$!!i" .
		NAPTR   100 10 "u" "http+I2C" 
"!^http://([^:/?#]*)(.*)$!http://\\1/\\2!i" .
		NAPTR   100 10 "u" "http+I2R" "!^(.*)$!\\1!i" .

Note that this time there is a value in the 'flags' field; a 'U'. This 
signals that
a match of the corrensponding regex means:

->	Terminal; do not evaluate any further.

->	And the result of the regex (if it matched) MUST be a URI.

Several other flags are defined.

Secondly you'll notice that the 'service' field contains something. The 
syntax is

	[ protocol ] [ '+' service >

Where protocol is any valid IANA service (see your /etc/services file); 
or ftp are well known examples and 'service' can be several values; 
above are

	I2R		Identifier to Resource -> give me the thing
	I2L		identifier to Location -> give me the location
	I2C		identifier to Characteristic -> give me metadata about the 

So lets now assume that we started this procedure out with the desire
to learn ABOUT the url, and that we speak http; then apply the above 

		NAPTR   100 10 "u" "http+I2R" "!^(.*)$!\\1!i" .

would match fine; we can do http, but we're not interested in I2R, so 
next we try

		NAPTR   100 10 "a" "z3950+I2C" 
"!^http://([^:/?#]*)(.*)$!!i" .

and this matches, we want I2C - but we're no dinosaurs; so we do not 
z3950. So next we try:

		NAPTR   100 10 "u" "http+I2C" 
"!^http://([^:/?#]*)(.*)$!http://\\1/\\2!i" .

this matches, and we can do http and we want I2C; so the fiinal result 

and the terminal type is 'U' - so I should interpret the above result 
as a URI. [3]

Apologies for any types/cut-and-paste errors in above - I'll spend some 
in the next week to simply the rules in our demo domain above to make 
it a
bit easier to follow.

On you can find some very rough 
ready code in perl/java which does the above; OR (better) you can cut 
paste the algorithm from RFC 3402 and 3404. Which probably is much 
(Though I'd love to hear if you open source your 
version of it :-).

C'est Ça



1:	Using abbreviated/simplified and not quite correct
	regexpes in perl style to make it easier to follow, the
	real ones are more complex to deal with escaping
	and match exact the URI def in the RFC.

2;	See rfc3401-3405 for exactly how when this is used; in
	general use the regex if there is a value or do outright
	substitution if it is empty with the replacement value.

3:	Other options are an SRV record or simply an IP

4:	Rfc 2396	Uniform Resource Identifiers

5:	Rfc 2915	NAPTR record

6.	Rfc 3405,


Received on Wednesday, 3 March 2004 05:53:49 UTC