[Simple] comments on draft-ietf-simple-rpid (long)

[Jonathan Rosenberg <[e-mail]>]

>             RPID - Rich Presence Information Data Format
>                        draft-ietf-simple-rpid-01

I actually think the title of this specification is confusing; it makes 
it sound like it is a separate format from PIDF. Can we rename to 
something like:

"Rich Presence: Extensions to the Presence Information Data Format (PIDF)"

which mirrors the naming convention used in the future status draft.

from the abstract:
> This information
>    can be translated into call routing behavior or be delivered to
>    watchers, for example.

This is a property that is not specific to rpid at all. Can we just drop 
the sentence? I think it would be useful, in the abstract, to add a 
sentence that summarizes what the extension covers. I suggest:

"This extension includes information about what the presentity is doing 
(the activity element), a grouping identifier for a tuple (the class 
element), the type of tuple (the contact-type element), whether a 
contact is idle (the idle element), the typle of place a presentity is 
in (the placetype element), whether the presentity is in a public or 
private space (the privacy element), the relationship of a tuple to 
another presentity (the relationship element), and the overall role of 
the presentity (the sphere element)."

> This extension does not replace media negotiation mechanisms defined
>    for SIP (e.g., SDP [8]), therefore media negotiation (e.g., choice of
>    voice and video codecs) MUST be performed according to RFC 3264 [10].

This is an odd statement for this specification, especially as the first 
sentence of the draft. Indeed, I dont think we can mandate rfc3264 per 
se; for example if sdp-ng came along than would rpid forbid it? Or a 
revision of rfc3264? I dont think so. I would rather strike this, and 
add an introduction to the spec. I suggest:

"The Presence Information Data Format (PIDF) defines a basic format for 
representing presence information for a presentity. That format defines 
a textual note, an indication of availability (open or closed) and a URI 
for communication. However, it is frequently useful to convey additional 
information about a user that needs to be interpeted by an automata, and 
is therefor not appropriate for placement in the note element of the 
PIDF document.

This document defines extensions to the PIDF document format for 
conveying richer presence information. Generally, the extensions have 
been chosen to provide features common in existing presence systems at 
the time of writing, in addition to elements that could readily be 
derived automatically from existing sources of presence, such as 
calendaring systems."

> This extension is only aimed to give the watchers hints about the
>    presentity's preferences, willingness and capabilities to communicate
>    before watchers initiate SIP-based communication with the presentity.
> 
>

I dont think there are any capabilities defined in RPID. Also, nothing 
about RPID or PIDF require SIP-based communication (though clearly I 
think thats the best idea ;) ).

> This memo makes use of the vocabulary defined in the IMPP Model
>    document [4].  Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
>    SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are
>    used in the same meaning as defined therein.  The key words MUST,
>    MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
>    OPTIONAL in this document are to be interpreted as described in BCP
>    XX, RFC 2119 [1].

I think you mean BCP 14.

> 3. The Meaning of "open" and "closed"
> 
>    PIDF describes the basic status values of "open" or "closed" only as
>    "have meanings of general availability for other communications
>    means". We define "closed" in our context as meaning that
>    communication to the contact address will in all likelihood not
>    succeed, is undesired or will not reach the intended party.  (For
>    example, a presentity may include a hotel phone number as a contact.
>    After check-out, the phone number will still ring, but reach the
>    chambermaid or the next guest.  Thus, it would be declared "closed".)
>    For "pres" contacts, "closed" means that no presence status
>    information is available.

I think this text is useful - I'm just not sure it belongs here. I 
suspect that it is, at this time, more appropriately located in:

http://www.ietf.org/internet-drafts/draft-sparks-simple-pdoc-usage-00.txt

> The namespace URIs for these elements defined by this specification
>    are URNs [2], using the namespace identifier 'ietf' defined by [3]
>    and extended by [5]:
> 
>       urn:ietf:params:xml:ns:pidf:rpid-status
>       urn:ietf:params:xml:ns:pidf:rpid-tuple

You might want to mention the motivation for multiple namespaces (I'm 
not sure I recall what it is).

> presentity. The activity indications correspond roughly to the
>    category field in calendar entries, such as Section 4.8.1.2 of RFC
>    2445.

You should probably provide a reference to RFC 2445.

>  An activity indication consists of one or more values drawn from the
>    list below, any other token string or IANA-registered values (Section
>    Section 7).

Double section. THis is a common xml2rfc error; <xref 
target="sec:section"/> will automatically put the word "Section" in.

> Communities of interest such as a profession or an
>    organization may define additional activity labels for their internal
>    use.

If so, don't we introduce the possibility of name collisions? If you 
really want this, you might need to do something like:

org.dancers-of-america.square-dancing

i.e, us some kind of vendor prefix.

But, I'd rather not do that, since we introduce yet another namespace 
management when we have a fine one in the form of XML. I'd rather allow 
only values defined from the ietf controlled registry.

> Depending on the presentity intent, all but the "available"
>    indication can be used with either status OPEN or CLOSED.
> 
>    Available: The presentity is available for communication.

indeed - what is the difference between <available> and open?

> Appointment: The presentity has a calendar appointment.

>  Meeting: This activity category can often be generated automatically
>       from a calendar.

what is the difference between these too?

> In-transit: The presentity is riding in a vehicle, such as a car, but
>       not steering. Alternatively, the presentity MAY offer more
>       specific information.

how does one offer more specific information?

> Busy: User is busy, without further details.  This activity category
>       would typically be indicated manually.

How does busy differ from closed? Also, I dont see a reason why it 
couldnt automatically be generated. For example, if I'm in a meeting.

> Permanent-absence: Presentity will not return for the foreseeable
>       future, e.g., because it is no longer working for the company.

what would this mean with open?

> and the time until which is element is expected to be valid.  The
>    'from' time MUST be in the past, the 'until' time in the future
>    relative to the publication of the presence information.

I think you need to be careful with the word "publication" here. If, 
right now, I publish a document saying that I'm in a meeting until 10pm, 
then at 11pm, the 'until' time is still in the future relative to the 
*publication* time, but not relative to the time at which the 
notification is sent. I think you need to say "transmission" and clarify 
that this includes either publication or notification.

> Contact-Type Element
> 
>    The <contacttype> element describes the type of the tuple.  A tuple
>    can represent a communication facility ("device"), a face-to-face
>    communication tuple ("in-person"), a set of devices offering a common
>    service ("service"), or a whole presentity ("presentity").
>    Additional types can be registered with IANA.

some of the rpid information only makes sense in one type of tuple or 
another (for example, sphere only makes sense for a tuple that 
represents a presentity, IMHO). Do we want to say, for each rpid 
element, for which it applies? Not sure if we want to go there in this 
doc, but I see it as a looming interop problem..


>  The <idle> records the absolute time and date the communication
>    device was last used.  This provides an indication as to how likely a
>    user is to answer the device.  A device that has not been used in a
>    while may still be OPEN, but a watcher may choose to first contact a
>    device that is both OPEN and not marked as idle.
> 
>    The <idle> element can be empty if the presentity wants to indicate
>    that the device has not been used for a while, but does not want to
>    reveal the precise duration:

These two paragraphs are contradictory. The first sentence says that the 
idle element records the *absolute time and date* the communication was 
last used, but the second paragraph says it can say nothing about when 
it was last used.

> The <idle> records the absolute time and date the communication
>    device was last used. 

This definition is subtlely different than its normal interpretation in 
existing IM systems. Here, "device" presumably refers to the device 
represented by the tuple, say the IM application. Thus, if I have not 
had an IM conversation in the last ten minutes, then presumably its now 
idle. However, in commercial IM systems, idle refers to the time since I 
last used the *computer*, which is not the same as the device in our case.

I thought briefly that idle only made sense with a tuple that represents 
a device, but then I thought of this case:

<tuple>
   <status>
    <basic>closed</basic>
    <contacttype>in-person</contacttype>
    <idle/>
    <activity>sleeping</activity>
   </status>
</tuple>

> public: The presentity is in a public area such as a shopping mall,
>       street, park, public building, train station, airport or in public
>       conveyance such as a bus, train, plane or ship. Alternatively, the
>       more detailed indications below may be provided.
> 
>    street: Walking in a street.

These partially overlap. Can I have more than one activity element to 
indicate both? Indeed, for all of the others, you might want to say 
whether I can only have one or many (the schema can't say).

>  bus: Public bus.

does this not include a private charter?

> The <placetype> element MAY be qualified with the 'from' and 'until'
>    attributes to describe the time when the element assumed this value
>    and the time until which is element is expected to be valid.  The
>    'from' time MUST be in the past, the 'until' time in the future
>    relative to the publication of the presence information.

same comment as above on publication.

> quiet: The presentity is in a place such as a library, restaurant,
>       place-of-worship, or theater that discourages noise, conversation
>       and other distractions.

isnt this more appropriate as a place-type? Seems orthogonal to privacy, 
since I can be at a library all by myself, or I can be in a library 
where the librarian is standing over my shoulder; in both cases the 
privacy is different.

> The <relationship> element designates the type of relationship an
>    alternate contact has with the presentity.  This element is provided
>    only if the tuple refers to somebody other than the presentity.
>    Relationship values include "family", "associate" (e.g., for a
>    colleague), "assistant", "supervisor".  Other free-text values and
>    additional IANA-registered values (Section Section 7) can be used as
>    well.

This seems like it should be a tuple-level element.

Also, in this case, presumably any other status elements would refer to 
the status of the alternate contact, not the presentity? For example, if 
busy, it means that the alternate is busy, not that the presentity is 
busy, right?

> 5.1 Presentity with Activity

This document is not valid. Several problems:

* its missing a namespace declaration for the XML schema schema, 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance", which is 
generally needed for the schemaLocation attribute.

*      <ep:activity>meeting</ep:meeting> should be:

<ep:activity>meeting</ep:activity>

* the <note> element needs to appear after the tuples according to the 
pidf schema; you have it before the tuples.

* the id attribute of the tuples are invalid. According to pidf, the id 
attribute is of type xsi:ID, which follows the production for NCName, 
which is:

NCName 	 ::= 	(Letter | '_') (NCNameChar)*	 /* 	An XML Name, minus the 
":" */
[5] 	NCNameChar 	::= 	Letter | Digit | '.' | '-' | '_' | CombiningChar | 
Extender

This cannot start with a number.

* tuple extensions (such as class and contacttype) need to come AFTER 
the status but before contact, note. You have them before status.

* you have contact as a child of status in the first tuple; its not, its 
a sibling

* the namepace prefix es should be ep

* the namespace declaration for pidf-status does not match the target 
namespace in the schema.

* The schema for activity is strange. It seems to require that activity 
be written like this:

<activity>
   <activity>meeting</activity>
</activity>

I dont think that was the intent.


Note that, in order to check the example document in an XML tool (I use 
XML spy), I had to change the pidf schema from lax interpretation of 
elements from other namespaces to strict interpretation. I shouldnt have 
had to do this; I'm not sure why XML spy wasnt validating extension 
elements even though I gave it a schema location for all of the 
namespaces in the document.

Here is the final doc I ended up with that appeared valid:

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" 
xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
entity="pres:[e-mail]" 
xsi:schemaLocation="urn:ietf:params:xml:ns:pidf
C:\DOCUME~1\jdrosen\MYDOCU~1\schemas\pidf-schema.xsd 
urn:ietf:params:xml:ns:pidf:rpid-tuple 
C:\DOCUME~1\jdrosen\MYDOCU~1\schemas\rpid-tuple-schema.xsd 
urn:ietf:params:xml:ns:pidf:rpid-status 
C:\DOCUME~1\jdrosen\MYDOCU~1\schemas\rpid-status-schema.xsd">
  <tuple id="c8dqui">
   <status>
    <basic>open</basic>
    <ep:relationship>assistant</ep:relationship>
   </status>
   <et:class>assistant</et:class>
   <et:contact-type>presentity</et:contact-type>
   <contact>sip:[e-mail]</contact>
   <note>My secretary</note>
  </tuple>
  <tuple id="x765">
   <status>
    <basic>open</basic>
    <ep:activity>
    <ep:activity>meeting</ep:activity></ep:activity>
    <ep:placetype until="2003-01-27T17:30:00Z">office</ep:placetype>
    <ep:privacy>quiet</ep:privacy>
    <ep:idle>2003-01-27T10:43:00Z</ep:idle>
   </status>
   <et:class>sip</et:class>
   <et:contact-type>service</et:contact-type>
   <contact priority="0.8">sip:[e-mail]</contact>
   <timestamp>2001-10-27T16:49:29Z</timestamp>
  </tuple>
  <tuple id="bs9r">
   <status>
    <basic>open</basic>
    <ep:privacy>quiet</ep:privacy>
   </status>
   <contact priority="0.8">im:[e-mail]</contact>
   <timestamp>2001-10-27T16:49:29Z</timestamp>
  </tuple>
  <tuple id="eg92n">
   <status>
    <basic>open</basic>
   </status>
   <et:class>mail</et:class>
   <nn:blah>blah</nn:blah>
   <et:contact-type>device</et:contact-type>
   <contact priority="1.0">mailto:[e-mail]</contact>
   <note>I'm in a boring meeting</note>
  </tuple>
</presence>


I'd strongly advise other folks to validate the schemas and example 
documents. Indeed, I have heard that other standards groups have had 
problems with schemas being OK in some tools, and not others. I think we 
should start to get into the habit of fairly rigorous validation of 
schemas and example documents as we get close to the stable point in the 
lifecycle of a specification. We all know how incorrect example SIP 
messages has been a nightmare for interoperability....


> 6. XML Schema Definitions

The status schema did not validate for me in XML spy. It was missing the 
targetNamespace attribute, which I recommend you add.

>  Note that this document does not need a new content type.  It
>    inherits the content type from [6], namely application/cpim-pidf+xml.

the MIME type has changed to application/pidf+xml (a source of much 
confusion, unfortunately).

> 7.1 URN Sub-Namespace Registration for
>     'urn:ietf:params:xml:ns:pidf:rpid-status'

this namespace doesnt match the one in the schema, which is  <xs:schema 
xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status"

> Description: This is the XML namespace for XML elements defined by
>       RFCXXXX to describe rich presence information extensions for the
>       status element in the PIDF presence document format in the
>       application/cpim-pidf+xml content type.

You need to tell rfc-ed to replace XXXX with the RFC of this spec.

> <h1>Namespace for rich presence extension (status)</h1>
>           <h2>application/pidf+xml</h2>

This is not a namespace, its a MIME type. Change to 
urn:ietf:params:xml:ns:pidf:status:rpid-status

Same two comments on 7.2

> 7.3 Place Type, Tuple Type, Activities, Relationships
> 
>    This document creates new IANA registries for activities, tuple
>    types, place types and relationships.  All are XML tokens.
>    Registered tokens must be documented at the time of registration, as
>    most descriptions are expected to be brief.
> 
>    The SIMPLE working group, or, if no longer available, the SIP working
>    group should be consulted prior to registration.

You need more instructions than that. You need to define the fields in 
the registration, what the procedure is for additions, amongst the 
choices in RFC2434, and give the initial tables based on the values in 
this document. I suggest that the registry not just include the token, 
but descriptive text about what it means.


Also, please register the schemas defined in the document. Registering 
schemas provides a stable URI reference for them, so that XML documents 
conformant to those schema can include the URL in the schemaLocation 
attribute.

> [5]  Mealling, M., "The IETF XML Registry",
>         draft-mealling-iana-xmlns-registry-05 (work in progress), June
>         2003.

This is now RFC3688.


Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple