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

Jon,

Jon>  While I
Jon> agree that these rules could be useful to other gatewayed services, the
Jon> scope of this WG is not to provide standards for any other matter than IM
Jon> and presence.

Formal working group scope is not a factor in having extraneous language in
a specification.

My original comment was that there was NOTHING in the normative
specification that is specific to IM or Pres. Hence, language that implies
otherwise is misleading.


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

One more time:  there is nothing in the normative text that is specific to
IM or Pres, so there no "revision that [makes] it more general" being
considered or suggested.  What is being suggested is removal of language
that implies a usage restriction that does not, in fact, exist in the
normative text.


>> << CPIM and CPP need to be defined.  For that matter, CPIM is

Jon> The title of the IM draft is now 'CPIM', and the presence draft is titled
Jon> 'CPP'.

The versions that are pointed to, by Mark's note, are not titled that way
and, in fact, both documents use their respective acronyms without
definition.  What is missing is the usual "This Is The Name (TITN)" form on
the titles.  There should also be an explicit definition of the acronyms the
first time they are used in the body of the specs.


Jon>  Incidentally, the paragraph before this does give the expanded
Jon> version of these acronyms.

Expanded, but not contracted. While it's possible that I am the only reader
who will fail to notice the correlation -- nevermind fail to figure out what
the acronyms mean.


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

The sentence is:

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

That suggests that the URI's "might" mean something other than expressing
identities.  Given your concern for working group scope, let me suggest that
expressing those identities is the only use for which we are considering it,
and that references to other things that "might" be, without actually
defining them, is entirely outside of scope, and probably distracting.


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

Jon> Well, the key word in the cited sentence is 'directly'. This particular
Jon> paragraph refers to carrying the URI as a literal in an IM protocol.

We are currently requiring that they carry the IMPP standardized content
format.

The lesson of two decades of email gatewaying is that a heterogeneous
address space ensures difficulties with address resolution and message
responding. If we are making everyone conform to the same content syntax, it
is no great leap to require the massive improvement offered by having
everyone conform to the same addressing syntax.

In any event, the URI is the URI, whether it is carried in native form or
not. There needs to be one, formal, official way to resolve it, lest there
by semantic confusion. Whether it is carried in its native form or not, the
URI has only one interpretation.

I think the difficulty here is that the spec is trying too hard to pay
attention to possible behaviors that are not being standardized, rather than
strictly focusing on the behaviors that ARE being standardized.  Or perhaps
the issue is that the spec is trying to hint at further pedagogy that one
"might" offer.  At best, this is outside the scope of this spec.


>> Note that the global semantics for email address resolution relies on
>> specific, mandatory DNS use of MX (and A records.) The URI activities
Jon> 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.")
>> 

Jon> Definitely agree with this (with the caveat that if there are no SRV
Jon> records, you must fall back to A records, etc).

Exactly as MX usage does.

(In fact, I find some of the text that is cloned from RFC 2821 to be
confusing, but decided not to raise a concern over it, since ultimately an
exact clone can have questions resolved with "do it the same as email MX,
but using SRV".)


Jon>  I don't really see how this
Jon> chaos is creeping into the draft from this sentence in the Introduction,
Jon> however. And the rules in Section 4 have normative text to this effect.

Most readers do not apply mathematical precision to their reading.
Introductory text which has extraneous and or misleading content will often
have more impact on the reader than the later, precise specification.


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]