ietf
[Top] [All Lists]

Re: The point is to change it: Was: IPv4 depletion makes CNN

2010-06-15 10:29:39
At Fri, 11 Jun 2010 23:30:03 -0400, Phillip Hallam-Baker
wrote, in response to a message from Masataka Ohta:

The URI syntax you specify is only used for some protocols and most of
the elements are defaulted. In fact we have got to the point where for
Web browsing everything is defaulted except for the domain name.

I think we need to break the idea that a Web service should have a URL
that starts HTTP.

Sounds reasonable, but below you obviously want to arrive at just
such a HTTP URI!


Rather, if we are connecting to the Google mapping Web Service we
would type in either

google.com   - if the type of service needed was obvious from the context
ws:google.com:maps   - for the fully qualified version


Under the covers this would of course expand via SRV to a http URL,
probably something of the form

http://services1.google.com/ws/maps/1/0
http://services2.google.com/ws/maps/1/0

Since the SRV record is expanding to a domain name that we presume to
be reserved for hosting of Web services we can take over the
specification of the URI stem in the protocol.

I'm getting confused very much.

DNS SRV RRs map a triple
     {domain name, transport protocol, service name}
to a target FQDN and a service port number (where the application
server is listening) -- setting aside the priority information,
which esentially allows to add redundancy and fallback, but no
additional kind of information.

So you already need to know the service name and the transport protocol.
That might be reasonable in your context.
But how do you envision to obtain the URIs (like those you show above)
from the RDATA in a SRV RR?

Did you have in mind a (yet unspecified) DDDS (RFC 3401-3404)
application, which would employ the use of DNS NAPTR RRs
(and then most likely SRV RRs as a 'backend') ?

NAPTR RRs can (with particular flag settings) produce an URI
out of a domain name and a service tag.  But please note that
NAPTR RRs contain the service tag as an embedded selector and
therefore need particular thoughts -- cf. the IAB deliberations
in RFC 5507.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah(_at_)TR-Sys(_dot_)de                    
 |
+------------------------+--------------------------------------------+

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf