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

Some further notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Monday, January 06, 2003 1:21 PM
> To: Peterson, Jon
> Cc: 'Dave Crocker'; [email protected]
> Subject: Re: draft-ietf-impp-srv-01.txt (was: Re: WG Last Call on
> multipl e documents (deadline Jan 12))
> 
> 
[snip]
> 
> 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.
> 

All right - although I don't think this should be a strike against the draft
given our current priorities (and that we are trying to conclude
expediently), I'll try to remove any impression that it would be forbidden
for another protocol to employ these dereferencing rules.

> 
[snip]
> 
> 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.
> 

I'll make the acronyms more explicit here and in the other drafts.

> 
[snip]
> 
>    "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.  

I agree that we don't want to suggest that these URIs might 'mean' something
else, no. We want to suggest that a protocol may or may not use these
schemes directly (that is, carry these URIs in their messages). We were
concerned that this would be impossible for some protocols that we would
like to consider gatewayable by CPIM, and so we wanted to leave a little
leeway here about that. Hence 'might'. I'll try to find a formulation for
this sentence that doesn't imply a mutable meaning of the URIs.

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

Totally agreed - hope the draft doesn't say otherwise.

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

Actually, this text in the Intro arose from the fact that people seemed to
be confused about how the im: and pres: schemes should be used - it was an
attempt to enumerate a few scenarios in which they were useful. There seemed
to be a strong sentiment that some examples of usage were necessary.
Formerly there was essentially no introduction - just the sections of
normative text.

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