draft-ietf-impp-srv-01.txt (was: Re: WG Last Call on multiple documents (deadline Jan 12))

Folks,

Detailed comments are below.

A general observation is that there is literally nothing in the normative
portion of this specification that is specific to IM or Pres.  It is simply
defining a mechanism for doing SRV-based address resolution among gatewayed
services.

Hence, the -im- and -pres- specifications should define their respective
URIs and then should cite this document as defining the means of performing
address resolution for their respective URIs, with this SRV document
containing no normative reference to IM or Pres, except as examples.

Detailed comments:

Abstract

   Presence and instant messaging are defined in RFC2778 [5].  The
   Common Profiles for Presence [2] and Instant Messaging [1] define two
   URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES.
   This document provides guidance for locating the resources associated
   with URIs that employ these schemes.

<< these are not "guidelines". this is a formal, technical specification
that is seeking standardization for address resolution using DNS SRV
records.  For example, note the force and precision of the language in
Section 4, below.
>>



   CPIM and CPP both specify operations that have 'source' and
   'destination' attributes.

<< CPIM and CPP need to be defined.  For that matter, CPIM is no longer our
specification. It has been superceded by the separate -im- and -pres-
specifications. /d
>>


    Such
   protocols might be able to use the 'im' and 'pres' URI schemes
   directly to express the identities of the principals associated with
   a protocol exchange.

<<
The use of the word "might" suggests that there are alternative means of
resolving -- and, therefore, of defining, these URIs.  I believe that use of
alternative methods that are indepedent of the SRV-based mechanism defined
here will render the address resolution service ambiguous, at best.

Note that the global semantics for email address resolution relies on
specific, mandatory DNS use of MX (and A records.) The URI activities being
defined in this document are subject to exactly equivalent need for
mandatory precision and uniqueness.

To be specific:

The domain name portion of these URIs MUST be subject to a single, global,
consistent resolution mechanism. The alternative is quite literally chaos
(which serves as a concise term to refer the otherwise inevitable address
ambiguity and address space fragmentation into isolated islands, typically
described as "what you get depends upon who you ask.")

This group has decided that IM and Pres shall have an end-to-end common data
representation syntax, as well as semantics.  It must do the same for
addressing.
>>


3. Address Resolution

   A client determines the address of an appropriate system running a
   server by resolving the destination domain name that is part of the

<<  "running a server by resolving"
     ->
     "running a server, on behalf of the system referenced by the domain
     name, by resolving" /d
>>


5. Processing SRV RRs
...
   The choice of IM transfer protocol is a local configuration option
   for each system.

<<
   "The choice of IM transfer protocol is a local configuration option
   for each system."
   ->
   Receiving systems that are registed for this DNS-based SRV resolution
   service list the transfer protocols by which they can be reached, either
   directly or through a translating gateway. The transfer-time choice of
   the IM transfer protocol to be used (and, therefore, to be resolved) is a
   local configuration option for each sending system.
>>




d/
-- 
 Dave <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850




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