Subject: [Simple] comments on rpids-01

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Jul 2003 10:10:46 -0400

From the abstract:

>   presentity and its contacts. This information can be translated into
>    call routing behavior or be delivered to watchers. 

You might want to add "for example" to the end. It makes it sounds 
like those are the only two things you can do with presence.

section 6.1:

> [7], using the namespace identifier 'ietf' defined by [8] and
>    extended by [9]:
> 
> 
>       urn:ietf:params:xml:ns:sip-rpids

I think it makes sense to define these within the pidf namespace. 
Thats what I did in the phone state draft. So, it would be:

urn:ietf:params:xml:ns:pidf:sip-rpids

However, as Jon had mentioned in his notes to the list, I think it 
makes more sense to perhaps break these up into groups of attributes, 
with differing namespaces for each. Namespaces are a very convenient 
way to group attributes, and to use for specifying filter and 
authorization policies. In xcap, we have permissions which allow for a 
watcher to see specific namespaces.

section 6.2:

>       Sleeping: This activity category can often be generated
>              automatically from a calendar or local time information.

or from the pressure of ones face on the keyboard when you fall asleep 
when working :)

>   In-transit: The presentity is riding in a vehicle, such as a
>              car, but not steering.

I think we might want more granularity here. I think there are useful 
distinctions between riding in a car and a plane, for example. So, I'd 
prefer to have a few vehicle-specific versions of this (obviously you 
need to draw the line somewhere, and I wouldnt include things like 
hovercraft or UFO...)

Also, there is "headset" which says that the user is wearing their 
headset on their wireless phone. Its also a common wireless handset 
style that can be automatically derived.

> 6.3 Card
> 
>    The <card> element provides a URI pointing to a business card, e.g.,
>    in LDIF or vCard format.

Don't we need to mandate a particular format?

> 6.5 From Element
> 
>    The <from> element indicates how long the current status has been
>    valid, expressed as an absolute time.

Wouldnt it make sense to apply this to a particular attribute 
(placetype, activity, etc.) rather than to the status element as a whole?

> 6.9 Type of Place Element
> 
>    The <placetype> element describes the type of place the presentity is
>    currently at. This offers the watcher an indication what kind of
>    communication is likely to be appropriate. We define an initial set
>    of values below:

Another one that appears on wireless handsets as a "style" is 
"Outdoors", which says that you are out and walking around. I think 
thats a useful one to add.

In the IANA registration for the sip-rpids namespace, the XML says:

>         <body>
>                     <h1>Namespace for SIMPLE rich presence extension</h1>
>                     <h2>application/cpim-pidf+xml</h2>

<h2> should contain the URN, not a content-type. This bug has been 
present in all of my XML-registering drafts for some time, and seems 
to have propagated.

You should register the schemas as well. This allows IANA to assign a 
stable URI that can be used in the schemaLocation attribute of import 
statements in schema declarations.

And one last nit:

>  Jonathan Rosenberg
>    dynamicsoft
>    72 Eagle Rock Avenue
>    First Floor
>    East Hanover, NJ 07936
>    USA
>    Email: [email-masked]

my address has changed, see sig below for updated info.

-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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 11:01:25 -0400

Jonathan Rosenberg wrote:

> I think it makes sense to define these within the pidf namespace. Thats 
> what I did in the phone state draft. So, it would be:
> 
> However, as Jon had mentioned in his notes to the list, I think it makes 
> more sense to perhaps break these up into groups of attributes, with 
> differing namespaces for each. Namespaces are a very convenient way to 
> group attributes, and to use for specifying filter and authorization 
> policies. In xcap, we have permissions which allow for a watcher to see 
> specific namespaces.

Agreed; but then you're contradicting yourself, i.e., they can't all be 
in PIDF, yet be in separate namespaces. Which do people prefer? (The 
schema currently keeps PIDF.)

> or from the pressure of ones face on the keyboard when you fall asleep 

Should I mention a detector attached to the microphone input, too? :-)

> need to draw the line somewhere, and I wouldnt include things like 

I've kept in-transit, as it allows generation by entities that don't 
know (e.g., a GPS that just monitors speed) or for presentities who 
prefer to keep their use of travel method private, but I'll add 
In-transit-ship, -motorvehicle, -aircraft, -train, -spacecraft. (By the 
time this draft gets to Full Standard, the latter will be a common mode 
of transportation. Plus, it explains those long delays...)

> style that can be automatically derived.

Wouldn't this be an orthogonal item, as in 
"in-transit-motorvehicle,headset"?

> Don't we need to mandate a particular format?

Why? The URI tells you how to retrieve it, the Content-Type what format 
it is and content-negotiation lets the watcher and owner of the 
information negotiate which format they both can deal with. After all, a 
single (HTTP) URI can point to objects of many different content types, 
languages, etc.

> (placetype, activity, etc.) rather than to the status element as a whole?

I agree that this is maybe better phrased as an attribute. In some 
cases, the whole tuple has been replaced at the <from> time, so there 
seems little point in marking each element with the same time. Is there 
sufficient value in allowing different times for different elements? I'm 
probably in favor, but this seems to get close to the line of adding 
complexity with little practical benefit to the watcher, but significant 
additional display complexity.

> thats a useful one to add.

How does this differ from a 'public' place like a mall or park? We 
already have public+quiet for the subset of public places where ringing 
cell phones or chatting are inappropriate.

> present in all of my XML-registering drafts for some time, and seems to 
> have propagated.
> 

What's the operative format for registering schemas?

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 11:01:25 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 20:35:28 -0400

> schema currently keeps PIDF.)

Sorry I am not being clear here.

What I mean is, these namespaces should be within the pidf umbrella. 
The suggestion above is:

i.e., its an additional namespace component below pidf. Thus, they are 
all within different namespaces (..pidf:predictive, 
..pidf:capabilities, etc.).

> of transportation. Plus, it explains those long delays...)

I'm not sure whether this was meant to be humorous or not... I do 
think its reasonable to have auto and plane, but clearly spaceship is 
a joke...

> "in-transit-motorvehicle,headset"?

Yes. I hadnt meant it to be part of the previous comment, sorry.

> single (HTTP) URI can point to objects of many different content types, 

OK, then I think we need to add mention that we are using http content 
negotiation (though I dont know if this exists in practice in web 
servers). More importantly, do we need a baseline 
mandatory-to-implement type?

> additional display complexity.

To me, the time that the tuple changed is not interesting at all. I 
don't want to know that "something changes 2 minutes ago". Its much 
more useful for me to know that "you got on airplace 2 minutes ago" 
or, "you got home two minutes ago".

> cell phones or chatting are inappropriate.

It conveys some amount of information on the range of where a user 
might be. "public" and "mall" means you are within the physical 
boundaries of the mall, and perhaps I can look for you. "public" and 
"outdoors" means you could be on the streets of manhattan, a much 
different size place.

I dont feel that strongly on this one. I suggested it primarily 
because it actually exists on phones I am aware of, and it would be 
nice to have a standard way of representing what exists today.

-Jonathan R.

> What's the operative format for registering schemas?

See the pidf-phone draft, which does it. Its really easy.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 20:35:28 -0400

-Jonathan R.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Jul 2003 06:26:00 -0400

Jonathan Rosenberg wrote:

> What I mean is, these namespaces should be within the pidf umbrella. The 
> suggestion above is:
> 
> all within different namespaces (..pidf:predictive, ..pidf:capabilities, 
> etc.).

I'm not sure I'm reading the PIDF spec correctly, but it seems to 
suggest that extensions are *all* within the status namespace (Section 
4.2.5), as in the example given in the spec

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

       <?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">
        [elided]

Maybe Jon can comment on what is intended here. (I guess it doesn't say 
that other namespaces, as in 4.2.4, cannot be standardized, but this is 
rather unclear in the PIDF text.) However, forcing a single extension 
namespace avoids that multiple standardized extensions all define 
elements with the same name, which would be confusing even with the 
namespace qualifier.

> Yes. I hadnt meant it to be part of the previous comment, sorry.

Given the IETF discussion, I wonder if this is really a phone status. If 
anything, it seems to be a capability (since it might make sense to ask 
for "mobile, but only with headset").

>> Why? The URI tells you how to retrieve it, the Content-Type what 
>> format it is and content-negotiation lets the watcher and owner of the 
>> information negotiate which format they both can deal with. After all, 
>> a single (HTTP) URI can point to objects of many different content 
>> types, languages, etc.
> 
> 
> servers). More importantly, do we need a baseline mandatory-to-implement 
> type?

Clearly, content-negotation is not exactly widely available, but I'm 
concerned about replicating this functionality in bits and pieces. I 
don't think that's technically advisable and may cause delays during the 
later document stages.

The HTTP spec does not mandate support for particular content types; 
given the politics around GIF and PNG, this might be a minefield. Maybe 
this should be part of the device requirements style documents such as 
the one Henry Sinnreich is putting together for phones. I'm not opposed 
to mandating a format (which?), but don't want to get dragged into a 
everybody-uses-GIF vs. GIF-is-still-patent-encumbered-in-Europe debate.

> don't want to know that "something changes 2 minutes ago". Its much more 
> useful for me to know that "you got on airplace 2 minutes ago" or, "you 
> got home two minutes ago".

Barring objections, I will make these parameters of 'activity', 
'placetype', and 'privacy'. I don't think they make sense elsewhere.

>> already have public+quiet for the subset of public places where 
>> ringing cell phones or chatting are inappropriate.
> 
> 
> It conveys some amount of information on the range of where a user might 
> be. "public" and "mall" means you are within the physical boundaries of 
> the mall, and perhaps I can look for you. "public" and "outdoors" means 
> you could be on the streets of manhattan, a much different size place.
> 
> I dont feel that strongly on this one. I suggested it primarily because 
> it actually exists on phones I am aware of, and it would be nice to have 
> a standard way of representing what exists today.

I've added additional options to the 'placetype', including outdoors, 
and moved the vehicle designation (ship, car, airplane, ...) there as it 
seems to fit better in that context.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Jul 2003 06:26:00 -0400

"The