Is cpim-srv document necessary at all? (Re: NAPTR and CPIM)

Pekka Pessi <[email protected]> 19 Nov 2002 08:09:55 +0200
Newsgroups gmane.ietf.impp
Message-ID <[email protected]>
	Hello all,

	Based on today's discussion in IMPP I now have came to the
	conclusion that the SRV lookup does no good (slow thinker, that
	I am).
	
	If a client can send the IM using the protocol that they have
	picked, they send the IM using it. Otherwise, they use a
	preconfigured gateway. In any case, they don't need a
	CPIM-specific DNS lookup but they will use the protocol-specific
	(SIMPLE, XMPP, Jabber, AIM, WV, what ever) method to resolve IM
	URIs.

	This has problems, however:

     1) When we know that the destination domain does not support our
	protocol of choice? Is it enough that there is no NAPTR/SRV
	records (or whatever) for our protocol, or should we try to
	resolve an AAAA record and send IM to the address there? What if
	the destination domain supports only legacy IP, should we
	resolve also A record and try send IM there, too? Who should try
	to do send IM to AAAA/A? Client? Gateway? Both? Do they try each
	IM protocol that they know?

	This problem applies to the current SRV-solution, too. A client
	or gateway simply cannot lookup SRV record for *all* possible
	CPIM protocols
	
	(I should mention here that if NAPTR was used, you could get a
	list of all IM protocols supported by a domain. If the DNS
	server was up-to-date, the response message to the initial NAPTR
	lookup would also contain SRV records *and* corresponding AAAA/A
	records of the preferred IM service.)

     2) The destination domain supports our protocol of choice, but
	how we know if it supports IM URLs using that protocol? For
	example, the destination domain uses SIP for telephony but
	Jabber for IM.

	I really don't know if this is a usual or even reasonable
	scenario, but in any case, I think this is a problem specific to
	the protocol, not a problem for CPIM.


	So, I propose that CPIM just settles on a solution for problem
	#1, and leaves the problem #2 to be solved by the protocols in
	question.

	Of course, this would be bad news for CPIM editor Jon Peterson
	(no more srv document? what I'm going to do with all this free
	time) but good news for SIMPLE chair Jon Peterson (kewl, yet
	another document to charter).

						Pekka



  [reminder: [email protected] for non-technical discussions, please]