impp@conference.ietf.jabber.com - 2002/11/18
[08:13] %% stpeter has arrived.
[08:17] %% stpeter has left.
[08:47] %% hildjj has arrived.
[09:00] %% hildjj has left.
[09:12] %% logger has arrived.
[09:17] %% logger has arrived.
[09:24] %% logger has arrived.
[09:25] %% hildjj has arrived.
[09:31] %% logger has arrived.
[09:52] %% hildjj has left.
[10:39] %% bensons has arrived.
[10:58] %% bensons has left.
[11:51] %% logger has arrived.
[17:27] %% abgallant has arrived.
[17:27] %% abgallant has left.
[17:29] %% warlord has arrived.
[17:37] %% hartmans has arrived.
[17:39] %% Joseph has arrived.
[17:41] %% jiri has arrived.
[17:43] %% lurker has arrived.
[17:44] %% lurker has left.
[17:45] %% andersa has arrived.
[17:47] <warlord> Welcome to the IMPP meeting.
[17:58] %% mrose has arrived.
[18:01] %% eblanton has arrived.
[18:03] %% eblanton has left.
[18:03] <mrose> is anyone going to transcribe?
[18:03] <mrose> general issue: is there are clear sense on the distinction between transaction ID and subscription ID in CPIM?
[18:04] %% eblanton has arrived.
[18:06] <mrose> mic: why not split pidf along the same lines as we did for cpim?
[18:08] <hartmans> Why do you need more statuses than open/closed to implement IM?
[18:10] <mrose> mic: what is the deficiency of using srv vs. naptr?
[18:11] %% jis has arrived.
[18:12] <mrose> jr: the reason that sip went to naptr is that it combines multiple records and orders them by priority
[18:13] %% hildjj has arrived.
[18:13] <mrose> chairs: do we need to resolve this issue?
[18:13] %% jis has left.
[18:14] <mrose> jon: let's just use one.
[18:14] %% jis has arrived.
[18:14] %% TonyHansen has arrived.
[18:15] <mrose> mic: but the srv thing is broken because, e.g., the text isn't sufficiently clear for interoperable implementation
[18:17] <mrose> jon: ah, we don't express a transport protocol in the SRV RRs described in the cpim draft
[18:17] %% NedFreed has arrived.
[18:17] %% leg has arrived.
[18:18] <mrose> jr: not really a problem, 'cause looking at the im protocol (e.g., sip), you'll eventually know what transport protocol to use
[18:19] %% pgmillard has arrived.
[18:21] <hartmans> So I haven't been following the list very closely, but the current
discussion seems to assume that SRV actually is needed for interop
at the CPIM layer.
Why?
Why is that not a matter for the the transport protocol?
[18:21] <mrose> dhc: would someone concisely summarize the problem?
[18:22] <leg> that wasn't a concise summary
[18:22] <mrose> jr: the problem is that when you do a SRV lookup you get back an IP addr and port number, but not an application protocol...
[18:23] <mrose> leg: heh, heh
[18:23] <jis> duh!
[18:23] <TonyHansen> it's overloading DNS to provide information it wasn't originally designed to provide
[18:24] <mrose> TonyHansen: so is it "too much" overloading or something we can ignore?
[18:24] %% klensin has arrived.
[18:24] <mrose> does anyone else in the room physically want to try to explain this?
[18:24] <TonyHansen> it's a short stretch rather than a long stretch, so I consider it within the realm of allowable
[18:25] <leg> IM URIs don't specify the transport (SIMPLE, APEX, etc.) so how do i contact the URI
[18:25] <warlord> dc has a good question..
[18:25] <leg> is that the problem?
[18:25] <hildjj> *shouldn't* the URI have the protocol in it?
[18:25] <hildjj> e.g. http://foo
[18:25] <hildjj> is http?
[18:26] <hartmans> leg: No, because your client already needs to know how to resolve the IM uri to use the SRV
[18:26] <leg> then what IS the problem?
[18:26] <TonyHansen> "im:foo@example.com" does not specify *which* im protocol is being used by foo@example.com
[18:26] <hildjj> the problem is the fact that there *is* an im URI at *all*.
[18:26] <TonyHansen> :-)
[18:27] <leg> what document defines an IM URI? i obviously don't understand something.
[18:27] <hartmans> Look at 2.2 in CPIM, don't know what section in split out new docs
[18:28] <warlord> The point of the im URI is to allow you to abstract the actual protocol...
[18:29] <hartmans> warlord but does the current SRV stuff actually do that usefully
[18:29] <TonyHansen> ditto for pres:foo@example.com
[18:30] <warlord> hartmans: I do not know offhand.
[18:31] <hartmans> Wait people seem to be thinking you can get an IP address and port. I don't even think that's true; am I misreading the current text?
[18:32] <hildjj> not all protocols need ip and port.
[18:32] <warlord> SRV _does_ give you an IP/port.
[18:32] <mrose> and some priority information, so you can order/randomize
[18:32] <hartmans> warlord: Yes, but I think I need to know what transport to use before I can do the SRV
[18:32] <warlord> er, he is correct, it's a Domain name + port.
[18:32] <hartmans> where transport is simple apex or xmpp
[18:33] %% leg has left.
[18:33] %% leg has arrived.
[18:33] <warlord> If the SRV returns sip:<domain-name> .....
[18:34] <leg> i like the "im:" is like a "mailto:" uri. that was helpful to me.
[18:34] <TonyHansen> don't forget prim :-)
[18:34] <hildjj> isn't mailto: up to the client, though?
[18:34] <hildjj> (and doesn't the client always pick SMTP in the real world?)
[18:34] <hartmans> But as I read the draft I understand that I need to know whether I'm using simple *in order to* know what SRV record to look up.
[18:34] <leg> inside a corporation with exchange or notes, no.
[18:35] %% aamelnikov has arrived.
[18:35] <warlord> Well, a client knows what protocols it speaks..
[18:36] <TonyHansen> I think the SRV lookup would be for the subset of the list of _sip._tcp.example.com, _apex._tcp.example.com, _xmpp._tcp.example.com, _prim._tcp.example.com, where the subsetting is based on the protocols that your client or gateway can understand
[18:36] <hartmans> OK, so the argument of why CPIM needs SRV is so that you can hatve a protocol independent mechanism to know whether a domain supports a particular protocol?
[18:37] <TonyHansen> yes
[18:37] <leg> he's right so far...
[18:37] <hildjj> not necessarily.
[18:37] %% klensin has left.
[18:38] <hartmans> Then allowing fall back to A records seems very wrong.
[18:38] <hildjj> yes.
[18:38] <hartmans> The current text allows fall back to A.
[18:38] <hartmans> s/current/text I read/
[18:39] <leg> well, if a site doesn't define any SRV records, you can go ahead and connect to a machine directly. maybe you win, maybe you lose.
[18:39] <hildjj> sorry. i meant yes wrt it's up to the gateway to translate uri's.
[18:40] <mrose> chair: ok, so are folks comfortable with what the srv draft is trying to do?
[18:40] <TonyHansen> if you're connecting via a gateway -- if you have a multi-protocol client, then you don't need a gateway
[18:41] <mrose> jon (the editor): i think i understand...the changes are editorial
[18:41] <hildjj> if i have a multi-protocol client, i need to know which of those protocols to use to talk to that user.
[18:41] %% grahamklyne has arrived.
[18:41] %% resnick has arrived.
[18:41] <hildjj> if all i have is im:, which do i choose?
[18:41] <TonyHansen> yes, the srv lookup that succeeds provides that information
[18:41] <leg> so, if i click on an "im:foo@example.com" URI in my browser, my IM client looks for SRV records corresponding to the protocol it supports in "example.com". if it finds one, it then attempts to make a connection with a IP & port.
[18:41] <mrose> chair: the fundamental idea is that when you come across an im/pres uri, you do lookups based on the protocols that you know how to use.
[18:41] <hildjj> which order do i use?
[18:41] <warlord> you choose the protocols you personally support.
[18:42] <hartmans> The draft needs to make it clear that I try all SRV lookups before any A lookups
[18:42] <leg> in whatever order you prefer
[21:09] %% logger has arrived.
[21:44] %% logger has arrived.
impp@conference.ietf.jabber.com - 2002/11/19
[06:33] %% mrose has arrived.
[06:38] <mrose> multiline
test
[06:43] <mrose> here is what the logger missed:
2035 <paul.knight> A: I want a protocol to be proposed to address this...
2037 <jis> David McGrew: Analysis of AES Counter Mode...
2037 <paul.knight> David McGrew - Counter Mode Security: Analysis and Recommendations
2037 <jis> Cm Can be implemented securely
2037 <jis> But is more vulnerable to precomputation attacks
2038 <jis> Because each packet doesn't have a random input (IV)
2039 <jis> Attacker can precompute data to use in attacking many traffic encrypting keys
2039 <jis> But it can be made better
2040 <jis> Need non-predicable initialization or use larger key
2040 <jis> (i.e., use random value field in initial counter)
2042 <paul.knight> Proposal is to use a randomizer in the initial counter value - it replaces the SPI, and is larger than the SPI field, using smaller IV and counter
2043 <paul.knight> shrinking the counter means it's hard to protect jumbograms
2047 <paul.knight> Since it's easy to add the security without incurring the computational tradeoff, we should probably consider this
2047 <paul.knight> Good list of questions in the presentation:
2048 <paul.knight> 85 or fewer bits of security acceptable?
2048 <paul.knight> inability to encrypt jumbograms acceptable?
2048 <paul.knight> implement and use AES-192?
2049 <paul.knight> Do we need an explicit IV? multiple receiver case vs. bandwidth is the tradeoff
2050 <paul.knight> For high bandwidth (10 Gbps) counter mode appears to be the only way to go; few IPR-free alternatives
2051 <paul.knight> crypto forum Research Group: www.irtf.org/cfrg
2052 <paul.knight> Q: Not sure of practicality of this attack..
2052 <paul.knight> A: Then are you saying 85 bits of security is enough?
2054 <paul.knight> Dave: want to get fast action on the list
2055 <paul.knight> Ted Ts'o - need to have good crypto review
2057 <paul.knight> Charlie Kaufman - Son of IKE Status
2057 <paul.knight> hanges
2058 <paul.knight> a la carte replaced by suites (controversial)
2058 <paul.knight> always 4 messages (controversial) etc etc.
2059 <paul.knight> NAT Traversal:
2100 <paul.knight> draft extending IKEv1 - does it apply to IKEv2? Should it be included in IKEv2?
2100 <paul.knight> Tunnel vs. Transport?
2101 <paul.knight> - not negotiated in IKEv2 .. is it needed? Interaction with NAT?
2102 <hartmans> What was always four messages?
2102 <paul.knight> MUST/MAY key sizes and algorithms .. no consensus clear
2103 <paul.knight> NUmber of messages: (IKE messages to create SA)
2104 warlord has arrived.
2105 <smb@research.att.com> (I'm writing up this whole talk, and will post when over.)
2105 <paul.knight> 4 messages unless: messages lost on network, initiator misguesses DH group, or initiator deciding he's under attack
2106 <hartmans> *sigh* I guess I need to pay attention to ikev2 with my Kerberos hat on
2106 <smb@research.att.com> I think that that's KINK anyway
2106 <warlord> Hmm, sounds like I need to get over there, eh?
2107 <smb@research.att.com> Not really -- not much discussion
2108 <paul.knight> Use legacy method before IKE? ... but recursion problems, especially with firewalls; may need PKI
2108 <mrose> just fyi: when the logger comes back up, i'll post the activity it missed when it was down.
2108 <smb@research.att.com> That's a strawman
2108 <paul.knight> For the true story, read Steve's write-up.
2110 <paul.knight> Did the volume of text kill the logger?
2113 <smb@research.att.com> it's a generic logger issue -- it vanished from many rooms.
2113 <mrose> paul.knight - no, the volume didn't kill it...the thing's some damn perl script...not what i'd call production code...
2113 pjnesser has left.
2114 <paul.knight> Suites, a la carte, or sweets a la carte?
2115 <smb@research.att.com> uite
2117 <smb@research.att.com> but that's my preference
2118 <warlord> I'm sort of mixed.
2118 <warlord> I like the ala carte ...
2118 <warlord> but there are certainly combinations that "dont work"
2118 <jis> which is why suites are good (as are sweets)
2120 <warlord> Yea, but you have to define n^2-epsilon suites as you add n different ciphers/hashes, etc.
2120 <jis> yep... but you don't *really* need to do that
2123 <warlord> No? Then what suites do I need to add when I want to add AES?
2123 <jis> You add an AES Suite with an appropriate Hash (SHA-256?)
2123 <smb@research.att.com> But new algorithms are added very rarely, and many combinations don't make sense
2123 <paul.knight> How many new ciphers are ikely in next 10 years? Hashes?
2124 <jis> Guess -> 5
2124 <jis> Or a working group (You have to be here)
2127 <smb@research.att.com> in the last 25 years, there have been exactly 3 *important* cipher choices -- des, 3des, aes (others are fads), and 2 or 3 hashes (md4 (maybe), md5, sha1). Double that for keyed hash vs. hmac
2127 <smb@research.att.com> ok, here come my notes on charlie's talk
2127 <smb@research.att.com> Changes in new draft:
suites (controversial)
JFK's 4 messages (always controversial)
JFK's traffic selector simplification
traffic selector narrowing clarification
crypto detail clarification
NAT traversal
use IKEv1 extensions with IKEv2?
Tunnel vs. transport negotiation
Not in v2
if inner==outer IP, MAY use transport instead of tunnel (some
say)
may interact with NAT
Key sizes and algorithms
1024 vs. 1023 vits? DSS support? MUST vs. MAY
consensus on change to certs
no consensus on suites vs. a la carte
Number of messages -- 4 unless
Messages lost on net (all)
Initiator misguesses DH group (JFK and old IKEv2)
Initiator decides being attacked (old IKEv2)
Cost of 4 mesgs
Complexity of statelessness
Partially-encrypted msg 3
Messages larger => UDP fragmentation
May impact legacy authentication
CRACK integrates better with oIKEv2
Legacy
Mostly road warrior
username/pw
securid
challenge/response card
OTP
Kerberos
others?
Past approaches to legacy auth
xauth
crack
ipsra/pic
Options
Ignore? Can't
Don't hold up IKEv2 while deciding (but 4 vs. 4/6 issue)
Use pw as shared key
dictionary attack
passwords only
design it in
sasl?
eap?
modify xauth/crack/pic?
start over?
Suites vs. a la carte
IKEv1 -- millions of possibilities/responder selects
oIKEv2 -- more efficient; same flexibility
JFK: responder selects one of (very) many possibilities (currently
small)
current IKEv2: propose subset of suites
Advantages of suites:
easier to specify and implement if number kept manageable
Advantage of a la card:
Easier if many
Easier to add new <xyz> and have it work, i.e., new elliptic
curve DH group wouldn't need all new suites
Options
Leave it as suites
change back to a la carte
cleverly-chosen multi-byte suite IDs
both? MUST suites, MAY a la carte?
Paul Hoffman's Revised Identity - several proposals wrapped:
certreq renamed TrustedRoot
dates back to isakmp
intended for bootstrapping directory access
used for listing trust anchors
current: DN of anchors
RI: SHA1(key of anchors)
charlie: copy TLS, whatever that does
allow URLs to certs
certs are large
UDP fragmentation
other end might already know
but -- can't always (no URL)
What's MUST, SHOULD, MAY for interoperability?
Negotiate authentication algorithms
new IDAccepted field
needed if multiple ways to authenticate and want to
autoselect
RSA cert, DSS cert, etc.
username/pw
other legacy
could be hidden in extended certreq
merge ID and CERT into FullID
today:
id required; cert optional
rules for matching id and cert unspecified
with legacy auth, things like CERTs (but not CERTs)
might be needed (i.e., Kerberos tickets)
proposal:
merge fields and allow more encodings
How do we reach RFC?
chose between multiple bales of hay
integrate nat traversal now or later?
integrate legacy auth now or later?
charlie's prefs:
crypto tweaks recommended by Hugo (and minor
tweaks from others)
chose the bales in the current spec (or decide
today)
work on nat and legacy in parallel with advancing
this spec
2129 <paul.knight> A point of extensibility has gotten lost in the suites vs. a la carte debate
2130 <paul.knight> Q: There is no use in publishing it if it does not support NAT. It's not the user's fault for being behind NAT.
2134 <paul.knight> Hillary Orman: issues not in key negotiation should be put into a different "policy" issue document (or WG?)
2136 <paul.knight> Problem with splitting things into other docs or WGs is that we lose momentum
2137 <paul.knight> Charlie: I didn't want to split things...
2139 <paul.knight> Jeff Schiller: rest of IETF wants to consume this technology. It's time.
2140 <paul.knight> We don't have to be perfect. If it doesn't finish soon, we will terminate it and the answer will be IKEv1.
2140 <paul.knight> I would like to see a timeline to get IKEv2 at IESG on Feb. 15 2003.
2141 <paul.knight> Go Jeff
2143 <paul.knight> Q: What does IKEv2 offer beyond IKEv1?
2144 <paul.knight> Jeff: Why are they waiting? To only implement it once.
2144 hartmans has left.
2144 <paul.knight> Jeff - let's resolve the 4 vs. 6 message question in the next 15 minutes. - A challenge!
2148 <jis> tick tick tick
2150 jis has left.
2153 <paul.knight> Can the chairs quickly put the proposals in writing on the screen before humming?
2154 <paul.knight> Humming supports 4/6 messages over 4.
2156 <paul.knight> Jeff: Next challenge: Suites vs. A la carte? 5 minutes!
2158 <paul.knight> Q: Make suites, but leave an extension mechanism
2201 <paul.knight> Jeff's question: Crypto suites or a la carte?
2201 <warlord> It;s a tie!
2204 <paul.knight> But when hands are counted, suites get about three times as many. I guess a la cartesians are louder.
2204 <warlord> I guess we are.
2204 smb@research.att.com has left.
2209 paul.knight has left.
2032 smb@research.att.com has changed the subject to: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/ipsec/
2158 jis has left.
2201 <paul.knight> Can the chairs quickly put the proposals in writing on the screen before humming?
2202 <paul.knight> Humming supports 4/6 messages over 4.
2204 <paul.knight> Jeff: Next challenge: Suites vs. A la carte? 5 minutes!
2206 <paul.knight> Q: Make suites, but leave an extension mechanism
2209 <paul.knight> Jeff's question: Crypto suites or a la carte?
2209 <warlord> It;s a tie!
2211 <paul.knight> But when hands are counted, suites get about three times as many. I guess a la cartesians are louder.
2212 <warlord> I guess we are.
2212 smb@research.att.com has left.
2216 paul.knight has left.
2234 mrose has left.
2243 warlord has left.
[06:44] <mrose> oops, wrong chatroom! here's the right one!
[06:45] <mrose> here's what the logger missed:
2035 Joseph has left.
2035 <hildjj> as a client writer, i'm glad i can use a gateway to do this.
2035 <hildjj> and just talk an easy protocol to a single server, and let the server do the right thing.
2035 <leg> if you have a local IM server, maybe you just send the message to it and it tries to find the right way of getting it through?
2036 <hildjj> leg: yep
2036 <hildjj> or, i know which gateway to use.
2037 <hildjj> the gateway can map uris in both directions.
2037 Joseph has arrived.
2037 <TonyHansen> email clients have a similar problem -- most email clients just have the user define an smtp server that they send the message to -- they do NOT try to send the messages directly to the specified domains -- they COULD, but don't because they took the easy way out
2037 <leg> and further most of us site admins are HAPPY that our clients are using our servers for relay.
2037 jhutz has arrived.
2038 <TonyHansen> I think IM clients are oing to be similar -- they'll have the user specify a gateway for the protocol the cilent supports, and punt on the issue of handling the other IM protocols
2039 <jhutz> perhaps, but the gateway will still have to deal with all the same problems
2039 <eblanton> e
2039 <leg> right, and all of these DNS SRV lookups are fine for a local IM server
2040 <jhutz> Now, the interesting question is...
2041 <jhutz> what if I (client or gateway) support multiple protocols? Then I probably want to use the "native" protocol of the person I"m talking to, so I can take advantage of whatever special features that protocol has.
2041 <jhutz> How do I find out which one is the "native" protocol?
2041 <hildjj> same as my question about order, i think.
2042 <hartmans> Jeff we had this discussion a bit ago; you don't care; you try in your local preference order
2042 <jhutz> Who says I don't care? I have full native support for multiple protocols. The protocols are not isomorphic, so if I choose the "right" one I get a richer set of features than if I choose the "wrong" one.
2044 <warlord> jhutz: you choose the one where you get more features first.
2044 <mrose> jon: an SRV RR looks like _im._sip.example.com, so the current approach appears to be acceptable.
2044 <mrose> chair: jon - do you undrestand what needs to be done to the draft
2044 <mrose> jon: can i see the minutes? heh, heh.
2045 <mrose> jon: we're requiring protocols that are gatewayable via cpim have a hook to be referencable by address and port
2045 <jhutz> warlord: that is begging the question. I get more features if I don't have to go through a protocol translator. That means I get more features if I use the same protocol as the other person.
2046 <mrose> dhc: service colon domain name, no ip address, no port number
2046 <jhutz> No. The results of an SRV record are priority, weight, domain name, and port
2046 <leg> we're very confused.
2046 <hartmans> dhc is talking about URI not the result
2047 <hartmans> O, never mind, dhc must not be talking about SRV
2047 <mrose> dhc: we want im:foo@bar.biz -> simple:bar.biz
2047 <mrose> lots of folks: that's not an srv
2048 <hartmans> I think dhc has just stated what we want quite clearly
2049 <mrose> chair: the basic architecture of what's in the srv draft is acceptable, but...
2049 <jhutz> I actually think what he described is in fact a good idea -- you should have a level of indirection where you get told what protocol and domain to use, rather than having to try them all.
2049 <jhutz> but the polling approach works too, I gues
2049 dcrocker has arrived.
2050 hta has arrived.
2050 paf has arrived.
2051 <hartmans> But I bet we have consensus that what dhc stated is the actual interop requirement
2051 <leg> i'm still not sure what the first DNS lookup dhc is suggesting starting from "im:foo@example.com".
2053 <hartmans> leg: dhc stated a requirement. So far no one has described an implementation
2053 <TonyHansen> remember what srv returns, besides weights, and other info useless for our purpose: a tuple of domain name and port. It's only with the naming convention of the SRv that we get the third piece of info you want: the protocol to use. If some DNS extension were able to return a protocol (or protocol list) in addition to domain+port, then we should be using it instead of SRV.
2053 <hartmans> Rather than the try all the protocols approach
2053 <hta> tony: "some dns extension" = NAPTR with adequate bells & whistles...
2054 <leg> if we want a lookup from "domain -> IM protocol", that's not a SRV record
2054 <warlord> Well, theoretically the srv could return a "domain name" that looked like "sip:example.com"
2054 <hartmans> hta: I think we're concerned that naptr may be too much
2054 <jhutz> But the naming convention of SRV records actually talks about a service and a transport protocol. A name like _im._sip.example.com does not follow that convention
2054 <jhutz>
2054 <mrose> jon the editor: i think i understand enough, but i don't know if the iesg will like a naptr-based solution, so we should probably stick with srv
2054 <paf> If you don't know the protocol for SRV's then you talk about using NAPTR to discover the protocol
2055 <TonyHansen> we need to go from "im:foo@example.com" to the triple: domain, port AND protocol
2055 <TonyHansen> so why does everyone hate NAPTR so much?
2055 <hta> hartmans: naptr as currently defined says that you have to profile it down for a specific app. if you need something as complex as that, using old ratholes rather than digging new ones might be a good idea.
2055 <warlord> jhutz: there is no reason you _NEED_ to use _im._tcp....
2055 <jhutz> Tony: No. We need to map from im:foo@example.com to an IM protocol and domain. _then_ we use a protocol-specific method (e.g. SRV) to find a hostname, port, transport protocol, and whatever else
2056 <TonyHansen> I'll agree to that clarification
2056 <leg> that's definitely not a SRV lookup. previously we were talking about probing a domain for the IM systems we supported, not querying the domain for what IM systems it prefers.
2056 <hartmans> Well, many of us first learned about NAPTR in Randy Bush's presentation about DNS sucking;-)
2056 <mrose> chair: do we have any other issues to discuss?
2057 <hta> those who believe that that presentation was strictly about the DNS didn't get the point......
2057 <TonyHansen> of course, gateways need to be able to advertise that they support >>multiple<< protocols
2057 <mrose> which "presentation"?
2058 <paf> Harald: I thought we talked about DNS only? :-)
2058 <TonyHansen> so im:foo@example.com really needs to map to a >>list<< of IM protocols supported by that server, and their domain names
2058 <jhutz> leg: correct. I believe dhc was trying to say that the right behaviour involves a level of indirection before the SRV lookup, which tells you what protocol to use and a domain that speaks that protocol, and then you don't have to do the polling thing
2058 <NedFreed> Can't a gateway do that by having multiple SRV records?
2059 jiri has left.
2059 <hta> presentation: http://www.ietf.org/proceedings/00dec/slides/PLENARY-3/index.html
2059 <leg> ned: yes. it depends on whether the sending system should request SRV records for IM systems it supports, or it should request a <blah> to find out what the target supports. i think it's really a wash which way you go.
2059 <paf> The way to do this in DNS is to first do a NAPTR lookup according to the dddns specifcation, only use the domain name, and get back a list of SRV's, one per protocol. You can even get back, if that is easier, a list of URI's.
2100 <TonyHansen> e
2100 <jhutz> yes, a list is a good idea. Assuming we're still talking about using the DNS to do the mapping, the way you do that is by returning multiple RR's. Of course, if you care about prioritizing the list, it gets a little more complicated. I don't think SRV is appropriate for this, unless you want to overload the RHS domain name as warlord suggests, and I really think that is sick
2100 <mrose> hta - thanks
2100 <jhutz> I guess I need to read up on NAPTR
2101 <NedFreed> It isn't clear to me what it means for a gateway to prioritize the protocols it supports.
2101 <NedFreed> I do this one better than this one?
2101 <hartmans> paf: Sure, and you can probably convince people that's right, but the reluctance for NAPTR is understandable
2101 <TonyHansen> that's where a weight comes in -- to provide a preferred order to the list
2101 <NedFreed> Ah. Yes, you could use SRV weights for that.
2102 <jhutz> If I have a URI im:foo@example.com, and example.com is native SIMPLE but also supports other protocols via a gateway, it may want to list SIMPLE first to encourage clients that understand SIMPLE to use it
2102 <NedFreed> But now you're talking about compaing weights from different SRV results.
2102 <paf> hartmans: I don't understand the reluctance, but, as Harald said, the problem is not only DNS.
2102 <TonyHansen> ned: details, details
2102 aamelnikov has left.
2102 <jhutz> Yes; SRV weights and even priorities could be useful here (you could list multiple gateways for the same protocol). But I still hate overloading the domain name. You might convince me that overloading the port in the SRV RR is acceptable. Maybe.
2103 <mrose> all: can some explain why this is the "last meeting"
2103 <NedFreed> My assumption was that the protocol was encoded into the SRV record name.
2103 <hartmans> You have some feature that most people don't know and many people know only as part of something that was a presentation about complexity. Reluctance to use that feature is understandable.
2103 <NedFreed> So if I have a client that support foo and bar I look for for.whatever and bar.whatever
2103 <leg> jhutz: a NAPTR lookup returns SRV records to lookup. you then lookup the SRV records.
2103 <NedFreed> And then I have to compare the two.
2104 <paf> I clearly see the need for someone to write down in detail how the resolution / discovery process is to work.......
2104 <hildjj> sorry all that the logger left. i'll wait a while for people to wander out, cut a snapshot, and have it posted at the above URL.
2104 hta has left.
2104 <paf> Consensus? :-)
2104 paf has left.
2104 <jhutz> Then you have do compare the weights across SRV records. Hmm...
2104 warlord has left.
2105 resnick has left.
2106 <NedFreed> May not be a problem for all I know. But there are a lot of weights floating around here.
2106 <TonyHansen> ned: not int the current srv draft -- it's part of the domain name to lookup
2106 dwillis has arrived.
2107 <TonyHansen> oops, meant to erase that, not send that :-(
2107 <NedFreed> Sorry, I don't remember the details of all this stuff.
2107 <NedFreed> K..
2107 andersa has left.
2108 jhutz has left.
2108 lgf has arrived.
2108 eblanton has left.
2108 <lgf> hey joe
2110 jiri has arrived.
2110 dwillis has left.
2113 leg has left.
2113 jiri has left.
2113 NedFreed has left.
2113 grahamklyne has left.
2120 TonyHansen has left.
2121 jis has left.
2121 lgf has left.
2122 Joseph has left.
2123 dcrocker has left.
2123 hildjj has left.
2128 pgmillard has left.
2144 hartmans has left.
1824 mrose has changed the subject to: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/impp
2118 dwillis has left.
2119 leg has left.
2120 jiri has left.
2120 NedFreed has left.
2121 grahamklyne has left.
2128 TonyHansen has left.
2129 jis has left.
2129 lgf has left.
2130 Joseph has left.
2131 dcrocker has left.
2131 hildjj has left.
2136 pgmillard has left.
2152 hartmans has left.
2234 mrose has left.
[06:45] %% mrose has left.
[08:10] %% pgmillard has arrived.
[08:11] %% pgmillard has left.