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

Jon,

Saturday, January 25, 2003, 4:53:33 PM, you wrote:
PJ> ... I think the concepts of <status> and <contact> are equally
PJ> applicable to voice, video, Internet gaming, and what have you. So
PJ> I don't think these elements really are specific to IM. In other
PJ> words, I think <status> and <contact> are valid normative concepts
PJ> for presence.

Yes, that makes sense.

I am more concerned that the core Presence spec be independent of IM
than I am about the particular, common elements that are part of the
core.  Any reasonable, minimal set is fine, as long as the spec
permits registering extensions.

So, again we agree: A common set of core elements that are defined as
presence functions with generic values. They can be mapped to any and
all specific presence "media" (or contexts, profiles, environments --
I am not sure what to call each of these "places" in which a
participant can have presence.) And there might be other elements that
are media-specific. These other elements need to be defined in
separate media-specific addenda.


PJ> It is also important to note that <contact> is optional in PIDF.
PJ> There could conceivably be forms of <presence> that would not need
PJ> a <contact> address.

It would not surprise me to see a "generic" addendum that is part of
many media-specific profiles.

However perhaps the right idea is, instead, to make such common
elements simply be optional parts of the core. That is, they have
common, generic definitions in the core document, but a particular
medium (context, profile, environment, ...) might not support them.

That would leave us with a core that has a set of defined elements.
Some are mandatory.  All environments must support them.  Others are
optional.  If an environment can support an optional element, it must
support it as defined in the core.  However an environment is not
required to have the function defined by the element.


PJ> However, I don't think this means that we need to field this out to
PJ> non-normative status. The concept of a communications address is, I think,
PJ> pretty integral to presence.

I continue not to understand what a "communication address" is,
relative to the URL being employed in the presence entry.

This needs to be made concrete, with examples, so there is some way to
know why it is required and what it will accomplish.  How is it
different from a URL?  How will it be used, differently from a URL?


>> >> It's fine to cite the others documents at the beginning and explain
...
>> 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.

PJ> The references largely appear in a section called 'Design Decisions' - it
PJ> uses RFC2778/RFC2779 to show our methodology, and why we've built the format
PJ> 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.
>> 

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

Whereas I am more concerned what implementors will appreciate.  And
they certainly will NOT appreciate having to bounce back and forth
among different documents to find a coherent, core specification.


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

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

PJ> Section 4.1.2 references 2778 for the definition of 'tuple'.
PJ> Section 4.1.4 references 2778 for the definition of OPEN and CLOSED.

put the definitions into the spec.


PJ> Section 4.2 references 2779 for the extensibility requirement of PIDF. This
PJ> could probably refer back to Section 2.1 (d) instead, agreed.

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

definitions of syntactic constructs are normative.


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

So forgive me for thinking that requirements documents were for
guidance in developing a specification and that specifications...
well, specify. Apparently, requirements documents specify, and
specification documents cite.

Believe it or not, implementors do not care about requirements
documents. They care about specifications. We should try to satisfy
our customers.


>> PJ> I agree that the title and remainder of the document should not use
PJ> this
>> PJ> older notation of 'CPIM'. I don't think we need to remove all
PJ> 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.
>> 

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

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

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

>>PJ> Actually, I think these words are still quite necessary. We still
PJ> intend
>> PJ> that there might be gateways that presence information will pass
PJ> through.
>> PJ> PIDF provides a format that can be shared end-to-end by different
PJ> 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.
>> 

PJ> This is something we've discussed before. I agree there is an important
PJ> semantic distinction between gateways and relays. However, I think what we
PJ> are doing falls well within the definition of gateways as the term is used
PJ> in other Internet applications.

A specification that imposes an end-to-end syntactic requirement --
especially one that is imposed without regard to the details of
dominant, existing systems, is not a specification of a gateway.  It
is a specification of an end-to-end service.

The fact that this working group has restricted the scope of
applicability to be for related IETF efforts, rather than including
non-IETF efforts, is a very clear indicator that we are not doing
gatewaying.


PJ> A presence gateway that converts SIMPLE into
PJ> APEX, say, without changing the PIDF body, is still a gateway, not a relay.
PJ> I think a 'relay' would be the term for a  SIMPLE-to-SIMPLE broker (just
PJ> like a mail relay is SMTP-to-SMTP).

You appear to believe that relaying requires that all of the details
be the same on both sides of the exchange.  They don't.  IP runs over
lots of different media.  The details are quite different.

Internet mail -- RFC822 objects -- has run over lots of different
email transfer protocols.  If the object is the same, it is very, very
tenuous to count the exchange between the two protocols a "gateway",
since it is not doing any significant translating.


PJ> Consider, for example, a mail-to-news gateway.

Mail and news have independent specification efforts.  They have
different addressing.  They have different packaging.  They have
different content.

The fact that there is overlap is essential for translation to
succeed.  The fact that the details are under independent control and
have divergent details, means that this is more than relaying.


PJ> Both mail and news (typically) use MIME.

MIME is not messaging.  THe discussion is about message translation.
MIME is a component of a message.  It is not the message.


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

See above. It's called gatewaying because it is translating between
independent, heterogeneous services. What this working group is
specifying constitutes essentially no translation. The message and the
object and the addressing are dictated on an end-to-end basis.


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

nope.


>> PJ> I think we want URI, actually. We define IM, for example, as a URI in
PJ> 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.
>> 

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

On the assumption that we are trying to make the specification
concrete and practical, please note that pres: is an address.  It is a
URL.  It says where to go to get the rest interpreted.  THe fact that
the 'location' is relevant and that the rest is 'interpreted' make
this an address.  URL means address.  URI means... gosh... identifier.
An identifier is significant for its uniqueness, not is semantics.


PJ> If we call IM addresses IM URIs, telephone addresses tel URIs, SIP addresses
PJ> SIP URIs, then I think saying that <contact> contains a URI is appropriate.

If you call IM addresses roses, they are still addresses, not
identifiers.


>> >>        - Communication address: communication means and contact
>> >>            address of this tuple. (optional)
>>
>> 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?

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

well, indeed that makes sense.  now I have to figure out why something
that straightforward was so hard for me to see, just in case I am not
the only dense reader who needs help.

>> 
>> >>    [[ 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
PJ> idea
>> PJ> that some forms of presence do not describe a communications
PJ> disposition.
>> 
>> Sorry but I do not understand what this means.  It would help to see
>> something concrete as an example of use.
>> 

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

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

PJ> Actually, I think if you allow extended status values, you are pretty much
PJ> already committed to multiple status values, because you may want to supply
PJ> <basic> status to ensure interoperability. If I define a richer status
PJ> vocabulary in an extension (consisting of: AWAY, IDLE, BUSY, etc), then
PJ> whenever I provide a rich status, I would also want to provide <basic> so
PJ> that watchers that do not support my presence extension will have at least a
PJ> rudimentary sense of my presence. This doesn't necessarily mean that all
PJ> rich status values have to reduce to OPEN or CLOSED (it's possible that some
PJ> would not), the fact that some could be reduced to OPEN or CLOSED suggests
PJ> 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
PJ> requirement
>> PJ> makes sense. We've all no doubt seen commercial IM&P systems with a
PJ> richer
>> PJ> status vocabulary. This extensibility allows individual services
PJ> employing
>> PJ> PIDF to choose richer statuses to their liking, while maintaining
PJ> 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.
>> 

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

PJ>    3.1.4. There MUST be a means of extending the common presence format
PJ>    to represent additional information not included in the common
PJ>    format, without undermining or rendering invalid the fields of the
PJ>    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
PJ> NOT be
>> PJ> used instead of <status>. 'Parent' above refers to XML parent. If
PJ> <note>
>> PJ> appears in <tuple> (<tuple> is its parent), then <note> should not be
PJ> used
>> PJ> as a substitute for <status>. In other words, it's arguing exactly
PJ> what you
>> PJ> are, I think.
>> 
>> I guess that proves that, the current language in the spec needs to be
>> easier to understand...
>> 

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

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

PJ> [snip]
>> >>    [[ How does a timestamp provide security?
>> >>    /d ]]
>> >> >>
>> >> 
>> 
>> PJ> It provids some limited replay protection. If you turn to the last
PJ> paragraph
>> PJ> of the Sec Cons, as the paragraph above suggests, you will see some
PJ> 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.
>> 

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



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



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]