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

Responses inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Sunday, January 05, 2003 10:06 PM
> To: [email protected]
> Subject: 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.
> 

This isn't pointing out any specific deficiency in the existing text, as far
as I understand, other than that the text may have more general
applicability. This is something that we've discussed here before. While I
agree that these rules could be useful to other gatewayed services, the
scope of this WG is not to provide standards for any other matter than IM
and presence.

I had remembered that our previous conclusion to this discussion was that we
should put this document forward as an IMPP-specific solution, and if it is
both implemented and perceived as useful by other gatewayed protocols, we
would explore a revision that made it more general as an individual
submission (or at least, not as a product of IMPP).

Is that plan really unacceptable for some reason?

> 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.

Okay... how about: "This document provides rules for locating..."

> >>
> 
> 
> 
>    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
> >>
> 

The title of the IM draft is now 'CPIM', and the presence draft is titled
'CPP'. Incidentally, the paragraph before this does give the expanded
version of these acronyms.

> 
>     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.  

Since in the Introduction we are enumerating ways that 'im' and 'pres' URI
schemes can be employed, 'might' here suggests one such alternative in a
disjunction (the same use of 'might' appears in the first sentence of the
fourth paragraph), as in: there are several different ways that the 'im' URI
scheme might be used by IM applications/protocols.

> 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.
> 

Well, the key word in the cited sentence is 'directly'. This particular
paragraph refers to carrying the URI as a literal in an IM protocol. As we
know, some protocols cannot carry 'im' URIs as a literal, and we did not
want to foist this upon all IM protocols. Would you prefer that we used a
stronger and less ambiguous term that required IM protocols to carry the URI
directly? 'Might' has the connotation that carring these URI schemes as
literals is not mandatory.

> 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.")
> 

Definitely agree with this (with the caveat that if there are no SRV
records, you must fall back to A records, etc). I don't really see how this
chaos is creeping into the draft from this sentence in the Introduction,
however. And the rules in Section 4 have normative text to this effect.

> 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
> >>
> 

Okay, no problem with that.

> 
> 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.
> >>
> 

I'm also fine with that text.

> 
> 
> 
> 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]
> 
> 



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