RFC 6157 actually updates RFC 3263 too - dual stack DNS lookups

"Olle E. Johansson" <[email protected]> Mon, 3 Oct 2011 19:58:15 +0200
Newsgroups	gmane.ietf.sipping
Message-ID	<[email protected]>
--===============0846922618637008509==
Content-Type: multipart/alternative; boundary="Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5"


--Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi!

I notice that RFC 6157 updates RFC 3264, but does not mention changes to =
RFC 3263.

RFC 3263 - locating SIP servers - repeatedly says: "the client performs =
an A or AAAA record lookup of the domainvname". Note the "or"


RFC 6157, section 3.1 says:

   Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
   for A resource records (RRs), an IPv6-only user agent will query DNS
   for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
   and choose a specific network.)



The clause about a dual-stack user agent clearly doesn't follow RFC =
3263, since it implies "and" instead of "or". There's no MUST, SHOULD or =
MAY language applied here, so it seems like this is an oversight - not =
that RFC 6157 is wrong, but that there should have been a more clear =
update to RFC 3263.

Nitpicking, but I think it's important to clarify the DNS functionality =
in regards to dual stacks. In addition, I think there's a need for a BCP =
to explain how a domain can indicate=20
preference of address family - ipv4 or ipv6 - by using SRV entries.

/O





--Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Hi!<div><br></div><div>I notice =
that RFC 6157 updates RFC 3264, but does not mention changes to RFC =
3263.</div><div><br></div><div>RFC 3263 - locating SIP servers - =
repeatedly says: "<span class=3D"Apple-style-span" style=3D"font-family: =
monospace; white-space: pre-wrap; ">the client performs an A or AAAA =
record lookup of the domainv</span><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; ">name". Note =
the "or"</span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; =
"><br></span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; =
"><br></span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; ">RFC 6157, =
section 3.1 says:</span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; =
"><br></span></div><div><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; "><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; font-family: Times; =
white-space: normal; "><pre class=3D"newpage" style=3D"font-size: 1em; =
margin-top: 0px; margin-bottom: 0px; page-break-before: always; ">   =
Furthermore, there SHOULD
   exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
   This allows the user agent to query DNS and obtain an IP address most
   appropriate for its use (i.e., an IPv4-only user agent will query DNS
   for A resource records (RRs), an IPv6-only user agent will query DNS
   for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
   and choose a specific =
network.)</pre></span><div><br></div><div><br></div></span><font =
class=3D"Apple-style-span" face=3D"monospace"><span =
class=3D"Apple-style-span" style=3D"white-space: =
pre-wrap;"><br></span></font><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; "><div>The =
clause about a dual-stack user agent clearly doesn't follow RFC 3263, =
since it implies "and" instead of "or". There's no MUST, SHOULD or MAY =
language applied here, so it seems like this is an oversight - not that =
RFC 6157 is wrong, but that there should have been a more clear update =
to RFC 3263.</div><div><br></div><div>Nitpicking, but I think it's =
important to clarify the DNS functionality in regards to dual stacks. In =
addition, I think there's a need for a BCP to explain how a domain can =
indicate </div><div>preference of address family - ipv4 or ipv6 - by =
using SRV =
entries.</div><div><br></div><div>/O</div><div><br></div></span><span =
class=3D"Apple-style-span" style=3D"font-family: monospace; white-space: =
pre-wrap; "></span></div><div><font class=3D"Apple-style-span" =
face=3D"monospace"><span class=3D"Apple-style-span" style=3D"white-space: =
pre-wrap;"><br></span></font><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; "></span><span =
class=3D"Apple-style-span" style=3D"font-family: monospace; white-space: =
pre-wrap; "><div><br></div><div><br></div></span></div></body></html>=

--Apple-Mail=_1CF51114-816D-4CD3-87E9-3CACD8AEF2C5--

--===============0846922618637008509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
--===============0846922618637008509==--