[Standards] UPDATED: XEP-0156 (A DNS TXT Resource Record Format for XMPP Connection Methods)

Peter Saint-Andre stpeter at jabber.org
Tue Jan 30 23:18:21 UTC 2007


Hi Matthias, as usual you are right...

Matthias Wimmer wrote:
> XMPP Extensions Editor schrieb:
>> Abstract: This document defines a DNS TXT Resource Record format for 
>> use in specifying methods of connecting to an XMPP server.
>>
>> Changelog: Removed _xmpp-client-tcpssl attribute since use of the 
>> old-style SSL-only port is discouraged. (psa)
> 
> Could we please remove _xmpp-client-tcp and _xmpp-server-tcp as well? I 
> very much feel, that these records are not good. 

The justification I have heard for _xmpp-client-tcp is the lack of SRV 
support in client-side libraries.

> Especially the 
> _xmpp-server-tcp record is very bad.

Yes I think _xmpp-server-tcp is really not needed. Push your service 
provider to support SRV. Server-side code should have access to a 
library that has SRV lookups (unlike client libs).

> For compatibility we already have to do up to four DNS lookups:
> 
> _xmpp-server SRV
> _jabber SRV

Let's deprecate _jabber SRV, shall we? I have already removed any text 
about it from rfc3920bis (version -01).

> AAAA
> A
> 
> Especially with slow nameservers this can take some time until the 
> connection is established.
> 
> Even if the _xmpp-server-tcp TXT record is discurraged, it only makes 
> sence to have it, if we REQUIRE servers to look it up. (Not requiring 
> this lookup would make the record completely useless and making servers 
> using it only available for a subset of the Jabber network.)
> 
> I don't think we sould introduce new records, that are discouraged to be 
> used from the beginning. Better we should start working at stopping to 
> support the old _jabber SRV record and focusing on _xmpp-server SRV.

Agreed.

> For _xmpp-client-tcp the disadvantages are not that problematic as 
> typically only a single serie of lookups is required at the startup of 
> the client. But still I think having a _xmpp-client-tcp TXT record type 
> only makes everything more complicated and we should not introduce 
> something that is discouraged from the beginning. And it confuses 
> admins, that try to use the records and have to notice, that most 
> clients will not support it (as usage is discouraged). One example for 
> this can be currently seen on the jadmin list.

I don't have a strong argument against your reasoning. It's certainly 
not a hill for me to die on.

Even the TXT records for things like http binding will be deprecated 
eventually if U-NAPTR takes off. But that might take a while. In the 
meantime, the TXT lookups for http binding etc. are helpful.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070130/8e01eb11/attachment.bin>


More information about the Standards mailing list