Re: PIDF issues summary (long)

Jon,

Apology for my delayed response.  

Your summary is greatly helpful to elaborate the PIDF draft, maybe to 
the expected level of IESG passing.  I appreciate your contribution very much.

I think most of your suggestions are reasonable and convincing, so
I'm editing the draft based on your text.  But, I still have questions and
comments on some of those, provided inline.

> Here is my own summary of issues/edits for PIDF. In most cases, I am
> speaking to different passages in the text than Graham did in his recent
> suggested edits. One point of overlap - Graham has proposed some text for
> modifying the last paragraph of 4.2.3 (where mustUnderstand is discussed). I
> feel that some additional changes are necessary to the second paragraph of
> 4.2.3, and I also have an alternative suggestion for replacing the final
> paragraph of 4.2.3 (my version normatively restricts the use of
> mustUnderstand to nested elements within extensions, which are always
> understood to be optional - Graham's text doesn't quite put the normative
> emphasis in the same place).

Comments below. 


> -- 2.2 Added Features --
> 
> To the end of (b), I suggest adding: "Note that this mechanism does not
> assume any global time synchronization system for watchers and presentities
> (see Appendix A of RFC2779, 8.1.4 A7), but rather assumes that watcher and
> presentities will be loosely synchronized."

Well, what is the exact meaning of  "loosely synchronized"?   I'm just 
asking if you used this with some special meaning.  I understant that 
an exact definition may not be required because this is the overview 
section, 

> -- 4.1.2 The <tuple> Element --
> 
> I would insert the following paragraph between the first and second
> paragraphs in this section:
> 
> "Tuples provide a way of segmenting presence information. Protocols or
> applications may choose to segment the presence information associated with
> a presentity for any number of reasons - for example, because components of
> the full presence information for a presentity have come from distinct
> devices or different applications on the same device, or have been generated
> at different times. Tuples should be preferred over other manners of
> segmenting presence information such as creating multiple PIDF instances."
> 
> I would also suggest appending the following to the last paragraph of this
> section: "Tuples that contain a <basic> status element SHOULD contain a
> <contact> address. Tuples MAY contain conflicting presence information - one
> <tuple> might provide a <basic> <status> of OPEN, and another <tuple> in the
> same PIDF could contain a <basic> <status> of CLOSED, even if they both
> contain the same <contact> address."

"Tuples MAY contain conflicting presence status" sounds better.  But, 
how should the application treat such conflicting tuples?   The description
in the suggested paragraph below ("If at least one tuple ...") seems more 
confusing.  Could you give more text for better understanding? 

> I would also suggest adding the following paragraph to the end of this
> section:
> 
> "The manner in which segmented presence information is understood by the
> watcher is highly dependent on the capabilities of the watcher and the
> presence application in question. In the absence of any application-specific
> or protocol-specific understanding of the meaning of tuples, watchers MAY
> obey the following guidelines. Watchers should note which tuples in the PIDF
> have changed their state since the last notification by correlating the 'id'
> of each <tuple> with those received in previous notifications and comparing
> both <status> values and <timestamp> elements in the tuples, if any are
> present. If at least one tuple in the PIDF contains a <basic> <status>
> element with a value of OPEN, then the presentity should be considered to be
> currently available. <contact> elements in tuples that do not declare a
> <basic> <status> of OPEN should not, however, be presented by the watcher as
> ways to communicate with the presentity at this time."

It seems there is confusion in the usage of the term "watcher", and some 
of those should be substituted by "WATCHER USER AGENT", 
e.g. in the last sentence.   Did you use the words "watcher" intentionally? 


> -- 4.2 Presence Information Extensibility --
> 
> Some information on the applicability of the extensibility mechanism would
> be useful here. I recommend appending a new paragraph to this section:
> "RFC2779 requires that PIDF have a means of extending <status> values beyond
> <basic>. The extensibility mechanism provided here These extensions MUST NOT
> modify how <basic> is to be understood, nor change the the structure or
> semantics of PIDF bodies themselves. These extensions merely allow protocols
> and applications to define richer presence data."

There seems to be an editing error in the third sentence.  Is it okay just to
delete "The extensibility mechanism provided here"? 

> -- 4.2.3 Handling of Unrecognized Element Names --
> 
> I think you should keep the first paragraph as it is, but for the second
> paragraph, substitute something like the following:
> 
> "Extensions to PIDF are informational in nature - they provide additional
> information beyond <basic> status. However, in order to understand a complex
> extension, nested elements within an extension element might need to be
> marked as mandatory. In such cases, the element name is qualified with a
> mustUnderstand='true' or mustUnderstand='1' attribute, which attribute name
> is associated with the CPIM presence namespace.See section 4.3.3 for an
> example."
> 
> Retain the editor's note (that serves as the third paragraph), and the
> fourth paragraph. I recommending substituting the following for the fifth
> paragraph: "If an agent receives PRESENCE INFORMATION with a <status> block
> containing an unrecognized element that has a mustUnderstand='true' (or '1')
> attribute, it should treat the entire element as unrecognized and not
> attempt to process it."

It seems that your wording does not explicitly prohibid the usage
of the "mustUnderstand" attribute in a direct child element of 
non-extensions, i.e. non-nested extension.  I think it's better to 
add a last paragraph provided by Graham with slight modification,
as follows. 

    "Note that the mustUnderstand attribute MUST NOT be used in a way 
    that might prevent a minimal implementation from understanding the basic
    PIDF information defined in this specification.  To ensure this, 
    the mustUnderstand attribute may be used only in elements within optional
    extensions, so that non-recognition of a mandatory extension results in no 
    worse than ignoring the optional extension in which it is contained."

Comments? 

> -- Security Considerations --
> 
> I suggest replacing the existing text with the following:
> 
> "Because presence is very privacy-sensitive information, the protocol for
> the presence information MUST have capabilities to protect PIDF from
> possible threats, such as eavesdropping, corruption, tamper and replay
> attacks. These security mechanisms must be able to be used end-to-end
> between presentities and watchers, even if the watcher and the presentity
> employ different presence protocols and communicate through a CPIM gateway.
> Since the 'application/cpim-pidf+xml' MIME type is defined for this PIDF
> document, staging security for PIDF at the MIME level (with S/MIME [x])
> seems appropriate. Therefore, PIDF should follow the normaivge
> recommendations for the use of S/MIME (including minimum ciphersuites) given
> in the core CPIM specification.
> 
> Note that the use of timestamps in PIDF (see section 4.1.7) can provide some
> rudimentary protection against replay attacks. If a watcher receives
> presence information that is outdated, it SHOULD be ignored. A watcher can
> determine that presence information is outdated in a number of fashions.
> Most significantly, if the timestamp on presence information is older than
> the last received presence information, it should be considered outdated.
> Applications and protocols also are advised to adopt their own rules for
> determining how frequently presence information should be refreshed. For
> example, if presence information appears to be more than one hour old, it
> could be considered outdated (a notification generated for this presence
> information will not take such a long time to reach a watcher, and if a
> presentity has not refreshed its presence state in the last hour, it is
> probably offline)."

The second paragraph seems to imply the timestamp is associated with 
presence information, but it is actually with a tuple.   It would be more
precise if, for example, the fourth sentence is replaced by 

    Most significantly, if the newest timestamp in presence information is 
    older than the newest timestamp in the last received presence information, 
    it should be considered outdated.

Hmm... I'm tending to like a timestamp associated with the whole presence
information as well. 


> -----
> 
> Nits:
> 
> - The last paragraph of 4.1.5 (on the <contact> element) talks about
> priority among tuples - surely this should be priority among contacts?

Right.  
 
> - The <tuple> 'id' attributes in the examples in 4.2.2, 4.2.4, 4.3.1, 4.3.2,
> and 4.3.3 should be changed from their current form (which specifies some
> sort of device or application name) to an opaque token, like a unique
> identifier. 

Okay. I'll change.

> - Is there a distinction intended between (d) and (g) in 2.1? If so, perhaps
> it should be clearer. If not, I'd suggest that (g) be removed (since (d)
> seems to be inclusive of (g)).

Removed.


Again, thank you very much for your careful reading and helpful suggestions.


-- Hiroyasu Sugano



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