RE: draft-ietf-impp-cpim-pidf-06.txt (was: WG Last Call on multip le documents (deadline Jan 12))

inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Friday, January 24, 2003 10:29 PM
> To: Peterson, Jon
> Cc: [email protected]
> Subject: Re: draft-ietf-impp-cpim-pidf-06.txt (was: WG Last Call on
> multip le documents (deadline Jan 12))
> 
> 
[snip]
>  He said:
> 
>              a) a format to carry any type of presence data (generally
>              speaking that is the <presence> and <tuple> elements)
> 
>              b) a set of attributes or presence schema pertaining to
>              IM or perhaps more broadly interpreted "communications
>              presence" (that is nearly everything inside the tuple,
>              except e.g. timestamp)
> 
> The key point is to separate normative text for Presence that is
independent of any
> particular medium like IM or email, and to specify normative text for
> medium-specific Presence information somewhere else.  Thanos cites
> another document.  I cited an Appendix.  The difference is not
> significant, for the point I was making and, apparently, he was
> making.
> 

Well, as I suggested, we had a thread then about how <status>, for example,
was not specific to IM at all. Nor is the concept of <contact>. Presence
concerns communications status, and the disposition of a presentity towards
particular avenues of communication. I think the concepts of <status> and
<contact> are equally applicable to voice, video, Internet gaming, and what
have you. So I don't think these elements really are specific to IM. In
other words, I think <status> and <contact> are valid normative concepts for
presence.

It is also important to note that <contact> is optional in PIDF. There could
conceivably be forms of <presence> that would not need a <contact> address.
However, I don't think this means that we need to field this out to
non-normative status. The concept of a communications address is, I think,
pretty integral to presence.

> 
> >> It's fine to cite the others documents at the beginning and explain
> >> that they provide requirements and definitions.  However the current
> >> specification need not reference those other documents for validity or
> >> for details. This is a specification document and it
> >> should try to provide a specification as independently as possible.
> 
> 
> PJ> Well, RFC2779 contains a lot of text that is intended to be
requirements for
> PJ> a presence information data format. Showing how this document
satisfies
> PJ> those requirements is important.
> 
> For a judicial review, yes it is important.  However that is not the
> job of a technical specification.  It needs to specify. It needs
> enough pedagogy to aid understanding and implementation.  That's all.
> 

The references largely appear in a section called 'Design Decisions' - it
uses RFC2778/RFC2779 to show our methodology, and why we've built the format
we did. 

> Having the document serve multiple purposes (specification vs. defense
> against claims that it does not match the requirements) reduces its
> effectiveness for both.
> 

Again, I think this is a very common practice, and one that I believe the
IESG appreciates.

> As I said, it is one thing to have the introduction contain some
> explanatory text and reference to the requirements document.  It is an
> entirely different matter to have the entire text sprinkled with cross
> references
> 

Here are all the references to 2778/2779 in cpim-pidf-07 after section 2
that I was able to find:

Section 4.1.2 references 2778 for the definition of 'tuple'.
Section 4.1.4 references 2778 for the definition of OPEN and CLOSED.
Section 4.2 references 2779 for the extensibility requirement of PIDF. This
could probably refer back to Section 2.1 (d) instead, agreed.

None of these are 'normative' references, as far as I understand the term.

I think it would be perhaps more troubling if PIDF defined OPEN and CLOSED
in a way that conflicted with the definition in RFC2778 - a reference is
preferable.

> 
[snip]...
> 
> In fact the document makes normative references to the requirements
> documents in a number of places.
> 
[snip]...
> 
> I would not have cited the issue unless I thought it did, as well as
> being distracting.
> 

Again, I don't think three references are very distracting, nor are these
references normative as far as I undersand the term (the don't appear in
sentences with any 2119 text).

> 
> PJ> I agree that the title and remainder of the document should not use
this
> PJ> older notation of 'CPIM'. I don't think we need to remove all
references to
> PJ> IM, however - I think it is valid to refer to IM as an example of a
> PJ> communication means used in the <contact> element.
> 
> Glad we agree that references to IM should be in examples, rather than
> normative text.
> 

Certainly we agree that the document should introduce no normative text that
restricts the applicability of PIDF to IM. Looking through the document,
though, I'm having a hard time seeing how it does. 

Assuming that we purge the term 'CPIM' and replace with 'CPP', the term 'IM'
doesn't appear in section of PIDF after Section 2, except in 4.2.5 as one of
a list of potential communication means that might be cited when registering
status extensions. The IM URI scheme appears in PIDF document examples (like
4.2.4). Even the usage of the term 'IM' in Section 2 is a citation from
RFC2779, and one that I think does not bias PIDF towards the IM application.

Can you point to any particular passage(s) in the existing draft where you
think this is a real concern?

> 
[snip]
> 
> PJ> Actually, I think these words are still quite necessary. We still
intend
> PJ> that there might be gateways that presence information will pass
through.
> PJ> PIDF provides a format that can be shared end-to-end by different
presence
> PJ> protocols that interconnect through a gateway.
> 
> Sorry, no.  The current effort has nothing at all to do with
> gatewaying.  This is an end-to-end object.  It does not get
> translated.  Gateways do translation.  Relaying is what is done to
> this object, not gatewaying.
> 

This is something we've discussed before. I agree there is an important
semantic distinction between gateways and relays. However, I think what we
are doing falls well within the definition of gateways as the term is used
in other Internet applications. A presence gateway that converts SIMPLE into
APEX, say, without changing the PIDF body, is still a gateway, not a relay.
I think a 'relay' would be the term for a  SIMPLE-to-SIMPLE broker (just
like a mail relay is SMTP-to-SMTP).

Consider, for example, a mail-to-news gateway. Both mail and news
(typically) use MIME. The job of a gateway is to convert the protocols
(SMTP/NNTP), while passing through the message body carried by these
protocols unchanged. Should this be called a "mail-to-news gateway" (hits on
Google: 11500) or a "mail-to-news relay" (hits on Google: 2)? 

I think our document in line with the accepted use of the term 'gateway'.

> 
> PJ> I think we want URI, actually. We define IM, for example, as a URI in
the
> PJ> impp-srv document.
> 
> Except for the few places where the UR* is simply used as a unique
> identifier  (eg., <id>) it is a locator.  Hence they all need to say
> URL, because that what they are.  Saying URI means, for example, that
> a URN might qualify, and that would be incorrect.
> 

Um... I'm not sure I would necessarily discount even a URN. Some URNs
resolved through the DDDS process, for example, could represent
communications addresses.

If we call IM addresses IM URIs, telephone addresses tel URIs, SIP addresses
SIP URIs, then I think saying that <contact> contains a URI is appropriate.
I wouldn't want to restrict it to resources that identify themselves as
URLs, anyway, since that could be read to disqualify all of the options I
just enumerated.

[snip]
> 
> PJ> Last I checked, SHOULD and RECOMMENDED were synonymous in RFC2119.
> 
> amazing.  never saw that.
> 
> why keep things simple when we can have so much fun juggling
> alternatives?   And, of course, the "strongly" helps the semantics
> quite a lot.
> 

I think the idea of having both SHOULD and RECOMMENDED is 2119 is to
facilitate phrasing requirements in the passive voice, Strunk and White be
damned. Agreed that STRONGLY is invariably a no-op.

[snip]
> >> 
> >>      o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
> >>      o List of presence tuples
> >>        - Status: OPEN/CLOSED for Instant Messaging or status for
> >>            other communication means.
> >>        - Communication address: communication means and contact
> >>            address of this tuple. (optional)
> >> 
> >> << ???  >>>
> >> 
> 
> PJ> ?
> 
> So much for my proofreading efforts.  Meant to add text asking what
> the heck a communication address is, compared with the presentity's
> URL?  How are the two different in specification and use?
> 

A pres URI is the address to which you send a subscription operation (and
from which notifications are received in the form of the presentity URL).
This isn't the address to which one sends instant messages, for example. The
point of having a separate contact address is that it is usually populated
with a URI appropriate for communicating: this could be a tel URI, an IM
URI, a SIP URI, etc. I definitely think these need to be distinct in PIDF.

> 
> >>    [[ What does it mean to have no communications means?  How is the
> >>    tuple used?
> >>    /d]]
> >>
> 
> PJ> The example that is constantly held up is geo-location - there is an
idea
> PJ> that some forms of presence do not describe a communications
disposition.
> 
> Sorry but I do not understand what this means.  It would help to see
> something concrete as an example of use.
> 

So, geographical location is an example of a form of presence that might not
include a <contact> address. Your location might be known to your PUA
because it contains a GPS chip, say, and you want to publish this location
information as presence. Well, if geographical location were in a <status>
element (assuming some new extension to <status> specified this), it's
pretty clear that this form of presence information would not necessarily be
associated with a communications address (you might not have an IM client or
any other communications application on your GPS device), whereas the status
of, say, a telephone is correlated with a communications address (i.e. a
telephone number). The fact that there are possible forms of <status> that
are not associated with a contact is why <contact> is optional in <tuple>. 

> >> 4.1.3. The <status> element
> >> 
[snip]
> >> 
> 
> PJ> It is essential to allow something beyond OPEN and CLOSED if we hope
it to
> PJ> be useful, yes.
> 
> The complexity I was referring to was "multiple status values".
> 

Actually, I think if you allow extended status values, you are pretty much
already committed to multiple status values, because you may want to supply
<basic> status to ensure interoperability. If I define a richer status
vocabulary in an extension (consisting of: AWAY, IDLE, BUSY, etc), then
whenever I provide a rich status, I would also want to provide <basic> so
that watchers that do not support my presence extension will have at least a
rudimentary sense of my presence. This doesn't necessarily mean that all
rich status values have to reduce to OPEN or CLOSED (it's possible that some
would not), the fact that some could be reduced to OPEN or CLOSED suggests
that there is value in providing both, and hence multiple values.

> 
> >>    [[ How is the requirement for minimality served by permitting
> >>    alternative, equivalent values?
> >>    /d
> >> >>
> >> 
> 
> PJ> Again, we inherit this from RFC2779. Personally, I think this
requirement
> PJ> makes sense. We've all no doubt seen commercial IM&P systems with a
richer
> PJ> status vocabulary. This extensibility allows individual services
employing
> PJ> PIDF to choose richer statuses to their liking, while maintaining
baseline
> PJ> OPEN/CLOSED functionality with other providers when both speak PIDF.
> 
> Having two different representations for the same semantics is not
> "richer".  It is, in fact, an invitation to greater complexity and,
> therefore, more bugs and less interoperability.
> 

Actually, as I hopefully made more clear in the paragraph above, I think it
allows extensibility with interoperability, which is exactly what RFC2779
asks us to do:

   3.1.4. There MUST be a means of extending the common presence format
   to represent additional information not included in the common
   format, without undermining or rendering invalid the fields of the
   common format.

> 
> >>
> >> 
> >>    Note that, wherever it appears, a <note> element SHOULD NOT be used,
> >>    and interpreted, as a non-interoperable substitute for status of its
> >>    parent element.
> >> <<
> >>    [[ You mean that it might be ok for a comment field, like <note> to
> >>    be used for something semantic, like status of parent???  This is
> >>    inviting non-interoperable.  Either the field is a human readable
> >>    content or it is machine-readable and needs to permit formal
> >>    definition.  (Anyone want me to cite yet another bit of experience
> >>    from email?
> >>    /d ]]
> >> >>
> 
> PJ> I think this sentence says exactly the opposite - that <note> SHOULD
NOT be
> PJ> used instead of <status>. 'Parent' above refers to XML parent. If
<note>
> PJ> appears in <tuple> (<tuple> is its parent), then <note> should not be
used
> PJ> as a substitute for <status>. In other words, it's arguing exactly
what you
> PJ> are, I think.
> 
> I guess that proves that, the current language in the spec needs to be
> easier to understand...
> 

Well, you may have been a little foxed by your reading of 'parent'. But how
about this text:

The <note> element SHOULD NOT be used to express presence status instead of
the <status> element - an arbitrarily populated block of text does not
provide an interoperable solution for sharing presence information.

[snip]
> >>    [[ How does a timestamp provide security?
> >>    /d ]]
> >> >>
> >> 
> 
> PJ> It provids some limited replay protection. If you turn to the last
paragraph
> PJ> of the Sec Cons, as the paragraph above suggests, you will see some
more
> PJ> text about it.
> 
> I don't think so, since an attacker can modify it.
> 
> Without encryption-based data integrity added to the timestamp, the
> timestamp adds nothing to security.
> 

This is obviously true - and although the paragraph in the Sec Cons above
the paragraph on <timestamp> discussed applying cryptographic properties to
PIDF, I suppose I agree that we should add something to the second paragraph
that makes it clear that the <timestamp> only provides replay protection if
the PIDF body is integrity-protected.

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