Subject: Re: pidf namespace, was: Re: [Simple] comments on draft-ietf-simple-rpid (long)

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Mar 2004 00:34:12 -0500

According to the RFC editor:

2003/10/29   draft-ietf-impp-cpim-pidf-08.txt
IANA
H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson
Presence Information Data Format (PIDF)
Bytes: 55276

IANA seems to be taken its time, but it seems late to try to change a 
fairly basic part of PIDF at this time.

The only limitation of using targetNamespace that there can't be another 
extension that also defines activity, relationship, etc., just in a 
different namespace. From a practical perspective, this seems like an 
advantage, not a drawback. Having two IETF extensions that use

<foo:activity>
and
<bar:activity>

seems to invite confusion to address non-problems (lack of coordination 
[these are IETF extensions, after all] and shortage of English words).

Jonathan Rosenberg wrote:

> I had forgotten about that bit.
> 
> Actually, the text in PIDF seems wrong to me. Here is what it says:
> 
>  Although the existing PIDF definition allows arbitrary elements to
>    appear in the <status> element, it may be sometimes desirable to
>    standardize extension status elements and their semantics (the
>    meanings of particular statuses, how they should be interpreted). The
>    URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a
>    namespace URI for extensions standardized by the IETF, and new values
>    in this namespace must be defined by a standards-track RFC.
> 
>    The following example XML Schema defines an extension for <location>
>    presence information, which can have the values of 'home', 'office',
>    or 'car'. If the <location> element were standardized, this document
>    would be made available in an RFC along with information about the
>    use of the extension. These extensions should use the namespace
>    'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an
>    extension should register an extension name within that namespace
>    with IANA.
> 
> This seems to suggest that all extensions actually have the namespace 
> urn:ietf:params:xml:ns:pidf:status, as opposed to being WITHIN that 
> namespace. That interpretation is supported by the example which follows:
> 
>   <?xml version="1.0" encoding="UTF-8"?>
>       <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
>            xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
>            xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            elementFormDefault="qualified"
>            attributeFormDefault="unqualified">
> 
> 
> note the target namespace.
> 
> I don't think this is right; each extensions should have its own namespace.
> 
> -Jonathan R.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Mar 2004 00:34:12 -0500

<foo:activity>
and
<bar:activity>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Mar 2004 00:51:30 -0500

Paul Kyzivat wrote:

>> 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.
> 
> 
> It differs because it means that you (probably) don't want to 
> communicate, not that you can't. A call will possibly result in alerting 
> the presentity. It may then result in no answer, or an answer from 
> someone who will be annoyed with you.
> 
> While it could be generated automatically, I think maybe the assumption 
> was that automated generation could be more precise. OTOH, it may be 
> that filtering will turn the more precise specifications into this one 
> in order to be less specific. So maybe the 2nd sentence should be removed.

Reworded to

User is busy, without further details. While this
activity would typically be associated with a status of CLOSED, a
presentity may declare itself busy to discourage communication, but
indicate that it still can be reached if needed.

> Maybe that the phone would ring without answer? Or that it would be 
> answered by whoever the phone number was reassigned to? (Aren't phone 
> numbers wonderful?)

Added sentence along those lines.

This interpretation implies that OPEN implies nothing about the 
usefulness of communication that is possible.

> I have a related issue that I thought I already raised, but maybe not.
> 
> I agree with your characterization of idle on commercial IM systems, and 
> that is probably what we want for those built with SIMPLE as well. But 
> when we extend the notion of presence to phones we typically get a 
> different semantic. It is common to be in close proximity to a phone and 
> yet not use it for long periods of time. So if idle is based on how long 
> since the phone was used, then a long idle time says nothing about the 
> likelihood that a call would be answered. And conversely, a lack of an 
> <idle> status likely increases the probability that a call won't be 
> answered.
> 
> So we end up with a status attribute whose significance is dependent on 
> the type of device publishing it. That seems like a bad thing. I'm not 
> sure what the solution is. Perhaps replacing idle with an attribute that 
> expressed a probability that the device is attended?

I can't see how a PC or phone could compute these probabilities. This 
would require knowing that 10 minutes of absence (the only observable 
value), for a particular user, implies that there's a 20% chance that 
the user has stepped out. Unless your PC or phone has a user proximity 
detector, this seems hard to do.

We do have the contact-type to allow the receiver to guess what this may 
mean. I think we discussed this before: in almost all cases, the value 
of a long idle time is not all that high (unless you know that the 
presentity is either a telemarketer who doesn't exist without a phone or 
a compulsive PC user that doesn't take his hands off the keyboard while 
in the office), but a short idle time is a good indication that somebody 
is likely home, be it a phone or PC.

Thus, my suggestion is to leave this as is and not try to over-interpret 
the value.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 02:16:41 -0500

> [these are IETF extensions, after all] and shortage of English words).

We've already done it:

<class> is defined in both
urn:ietf:params:xml:ns:pidf:rpid-tuple and in 
urn:ietf:params:xml:ns:simple-prescaps-ext.

It isn't too bad, because they can't be used in the same context. The 
rpid class can only be used directly below <tuple>, while the prescaps 
class can only be used within <prescaps>.

	Paul

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 02:16:41 -0500

We've already done it:

	Paul

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:05:22 -0500

inline.

Henning Schulzrinne wrote:

>> communicate, not that you can't. A call will possibly result in 
>> alerting the presentity. It may then result in no answer, or an answer 
>> from someone who will be annoyed with you.
>>
>> While it could be generated automatically, I think maybe the 
>> assumption was that automated generation could be more precise. OTOH, 
>> it may be that filtering will turn the more precise specifications 
>> into this one in order to be less specific. So maybe the 2nd sentence 
>> should be removed.
> 
> 
> Reworded to
> 

OK.

> usefulness of communication that is possible.

Well, this directly contradicts the text that is currently in the 
beginning of rpid:

>  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 agree with your characterization of idle on commercial IM systems, 
>> and that is probably what we want for those built with SIMPLE as well. 
>> But when we extend the notion of presence to phones we typically get a 
>> different semantic. It is common to be in close proximity to a phone 
>> and yet not use it for long periods of time. So if idle is based on 
>> how long since the phone was used, then a long idle time says nothing 
>> about the likelihood that a call would be answered. And conversely, a 
>> lack of an <idle> status likely increases the probability that a call 
>> won't be answered.
>>
>> So we end up with a status attribute whose significance is dependent 
>> on the type of device publishing it. That seems like a bad thing. I'm 
>> not sure what the solution is. Perhaps replacing idle with an 
>> attribute that expressed a probability that the device is attended?
> 
> 

I'd really rather not; I think its a mistake to produce an idle 
attribute that differs substantially from established semantics. This is 
one of the few pidf extensions that we know is widely used in existing 
systems, and is a clear requirement for us to provide.

I would instead propose that we define an attribute like <device-idle> 
which makes it clear that this refers to the idle time on the DEVICE on 
which that particular tuple is associated. A natural consequence of this 
is that it wouldnt make sense for tuples that span devices or are 
otherwise not associated with a device. I'd also suggest adding text 
that makes it clear that, in the one case of an IM app on a PC, that 
this has the commonly understood semantics of idle.

We may or may not also want idle as you have defined it; I am more 
agnostic on that point, but would suggest renamining it if it is 
included, to avoid confusion.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 09:55:47 -0500

I think its a mistake to try and avoid collisions in the local part of 
an element name. This is EXACTLY why namespaces were invented, as Lisa 
pointed out during the session. Jon indicated that his intent for the 
document was that pidf extensions are registered BENEATH 
urn:ietf:params:xml:ns:pidf:status, which is fine. If its just an issue 
of poor wording and an incorrect example, I would hope that can be 
corrected during auth48. Certainly it should not stop us from doing what 
is, IMHO, the obviously right choice.

-Jonathan R.

Paul Kyzivat wrote:

>> The only limitation of using targetNamespace that there can't be 
>> another extension that also defines activity, relationship, etc., just 
>> in a different namespace. From a practical perspective, this seems 
>> like an advantage, not a drawback. Having two IETF extensions that use
>>
>> <foo:activity>
>> and
>> <bar:activity>
>>
>> seems to invite confusion to address non-problems (lack of 
>> coordination [these are IETF extensions, after all] and shortage of 
>> English words).
> 
> 
> We've already done it:
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:52:17 -0500

inline.

Henning Schulzrinne wrote:

>>> 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?
> 
> 
> I'm not sure this is useful; it was meant to allow inclusion of the 
> 'activity' even if there was no other activity to report.

I dont see value in that; I would propose to remove it.

> 
> 
>>
>>> 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?
> 
> 
> A meeting is a sub-class of appointment; appointment includes my visit 
> to the dentist and attending my son's soccer game.

OK. Can we clarify that in the text?

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

OK. It wasnt clear to me that what you meant by more specific 
infomration was one of the other values for this.

>>
>>
>> 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.
> 
> 
> How about relative to the 'timestamp' element?
> 
> 

I think thats OK. Timestamp is optional. When used with this element we 
would need to make it mandatory.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 01 Mar 2004 11:05:13 -0500

Jonathan Rosenberg wrote:
>> 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.

I don't see how <activity> values (which is character content) can be 
made extensible with XML based mechanisms alone, at least not in its 
current form. If you want to publish a pidf/rpid doc with 
<rs:activity>square-dancing</rs:activity>, how do you indicate that the 
"square-dancing" value belongs to some non-rpid XML namespace (say 
http://dancers-of-america.org/)?

Maybe having an additional level of elements, as in

<presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:rs="urn:ietf:params:xml:ns:pidf:rpid-status"
     xmlns:doa="http://dancers-of-america.org/"
     entity="pres:[email-masked]">
   ...
     <rs:activity>
       <doa:activity>square-dancing</doa:activity>
     </rs:activity>

would work although it seems like rather a lot of machinery. Is this 
what you had in mind?

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:06:20 -0500

Paul Kyzivat wrote:

> Jonathan,
> 
> You really went thru this with a fine toothed comb! I have a couple of 
> comments below.
> 
>     Thanks,
>     Paul
> 
>>> 3. The Meaning of "open" and "closed"
>>>
>> 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 meaning of open and closed in pidf is normative. If we need to 
> extend the definition of open and closed, then it needs to be in a 
> normative document. The pdoc-usage document won't be normative, so it 
> can't be the right place.

I dont agree. I dont think the text above is changing the normative 
behavior, its merely expanding on its usage to make it clear.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 01 Mar 2004 11:05:13 -0500

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:52:17 -0500

inline.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:06:20 -0500

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 09:55:47 -0500

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 10:05:22 -0500

inline.

OK.

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 00:02:58 -0500

> behavior, its merely expanding on its usage to make it clear.

I think the above *wants* to extend the normative behavior. Currently 
the only normative behavior we have for non-IM communications is:

    The values "open" and "closed" indicate availability to receive
    INSTANT MESSAGES if the <tuple> is for an instant messaging address.
    They also indicate general availability for other communication
    means, but this memo does not specify these in detail.

It is useful to say more in a normative way - to sharpen up the 
definition. Adding the same language in an informative document doesn't 
have the same significance.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2004 00:02:58 -0500

Paul

---

From: Alex Audu <[email-masked]>
Date: Tue, 02 Mar 2004 13:50:36 -0600

Hello Henning,

Please find my comments inline.

Henning Schulzrinne wrote:

> [snip]
>> and that is probably what we want for those built with SIMPLE as 
>> well. But when we extend the notion of presence to phones we 
>> typically get a different semantic. It is common to be in close 
>> proximity to a phone and yet not use it for long periods of time. So 
>> if idle is based on how long since the phone was used, then a long 
>> idle time says nothing about the likelihood that a call would be 
>> answered. And conversely, a lack of an <idle> status likely increases 
>> the probability that a call won't be answered.
>>
> We do have the contact-type to allow the receiver to guess what this 
> may mean. I think we discussed this before: in almost all cases, the 
> value of a long idle time is not all that high (unless you know that 
> the presentity is either a telemarketer who doesn't exist without a 
> phone or a compulsive PC user that doesn't take his hands off the 
> keyboard while in the office), but a short idle time is a good 
> indication that somebody is likely home, be it a phone or PC.
>
> Thus, my suggestion is to leave this as is and not try to 
> over-interpret the value.

Shouldn't this probability be configured instead computed? 

Alex.

---

From: Alex Audu <[email-masked]>
Date: Tue, 02 Mar 2004 13:50:36 -0600

Hello Henning,

Alex.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 00:58:40 -0500

Unless somebody strongly disagrees, I'd like to just keep it in the 
document rather than wait for some unrelated, very early document to 
become ready. At worst, we end up duplicating a paragraph of fairly 
mushy text. (I.e., it just describes general system behavior, not really 
protocol operation.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 00:58:40 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 06:57:23 -0500

As far as I can tell, it is not possible in XML schemas to add tokens 
later (e.g., by IANA registration). Thus, checking has to be done 
outside of the schema verification.

Regardless of that, I'm inclined to leave this as IANA-registered, 
although relying on IANA seems like a dicey proposition where only 
institutions with a sense of time like the Catholic church would have 
the patience to register additional activities (or other similar items).

I suspect that rather than collision, the most difficult issue, either 
with namespaces, IANA registration or free-for-all, is allowing 
automated handling by UIs and policy languages since it requires 
upgrading lots of deployed systems.

Other suggestions are most welcome, but I'd like to wrap this up.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 06:57:23 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 07:17:43 -0500

> infomration was one of the other values for this.

Actually, re-reading the section leads me to believe that this was an 
artifact of an earlier version where some of the placetypes were in 
'activity'. I have reworked the link.

> would need to make it mandatory.

I've added an 'if available' half sentence.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 07:17:43 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 07:27:35 -0500

> Well, this directly contradicts the text that is currently in the 

Since permanent-absence and OPEN is indeed a stretch, I'll just declare 
this for CLOSED only.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Mar 2004 07:27:35 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Mar 2004 22:08:48 -0500

Jonathan Rosenberg wrote:

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

 From what I can tell, all of them (except <idle>) really make sense 
only for presentity and in-person, if you're strict about this. However, 
since a presentity may only export a device view, i.e., an enumeration 
of a bunch of contact-type=device tuples, it would then be impossible to 
convey RPID information. Another aspect is that often, it is one device 
that knows this information (e.g., that has a calender interface).

Thus, I don't see how restricting this helps much. The only solutions I 
can see are:

(1) Allow use as extensions of <presence>, not <status>. This makes some 
sense as this information does apply to the whole presentity, but 
doesn't work well if multiple tuples are presentities (secretary, 
principal).

(2) Variation of (1): allow both, but only in <tuple> if tuple is 
contact-type 'in-person' or 'presentity' and has a relationship.

(3) Not worry about it: the UI simply takes all the information about 
the devices or services and presents them either with one device (to 
indicate their source) or the union of them for the presentity.

(3) is probably expedient, (2) the better data model. I'd like feedback 
on this, as it is a major design decision.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Mar 2004 22:08:48 -0500

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 14:30:49 -0500

> upgrading lots of deployed systems.

Sure; but thats a separate problem.

I rather like Ander's suggestion of having the content of the activity 
element be another element, which has no value and whose name is the 
actual activity. Then, you can use XML namespaces to get what you want.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 14:30:49 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 Mar 2004 21:13:42 -0500

> actual activity. Then, you can use XML namespaces to get what you want.

It's a bit messy, but I'll modify this to allow

<activities>
   <activity>sleeping</activity>
   <activity>vacation</activity>
   <si:activity>REM</si:activity>
</activity>

(where si is the namespace owned by your neighborhood sleep institute)

Multiple activities can occur primarily by composition. This is probably 
only likely if there are <relationship> tuples involved, but there might 
be other cases where activity information is derived from multiple sources.

Given that this is somewhat messy, I'm reluctant to do the same thing 
for <placetype> and <privacy>, but if somebody insists...

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 Mar 2004 21:13:42 -0500

<activities>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Mar 2004 00:51:30 -0500

Reworded to