Subject: [Simple] WGLC Extension for RPID, CIPID and future status

From: [email-masked]
Date: Wed, 12 May 2004 10:38:37 +0300

The WGLC for RPID, CIPID and future status has completed. Unfortunately, they did not get enough comments or reviews and therefore the SIMPLE WG chairs will not pass those drafts to IESG for consideration yet. We have decided to extend the WGLC until May 24th hoping that more reviews, commented and consensus that the drafts are ready can be gathered.

http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-future-01.txt

Regards,
Hisham

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 12 May 2004 16:24:50 +0300

Henning:

Some comments to the working version of the RPID draft:
http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-04.html

- The most important concern is regarding the extensibility of tokens in 
XML. This draft defines several elements (e.g., <contact-type>, 
<placetype>, <privacy> and <relationship> that only accept one of the 
listed tokens. This means that an XML validator will check that the 
value is one of the defined tokens, and if not (e.g., a new token), will 
reject the document. However, the draft also allows extensibility of 
these tokens through IANA registration. To me, XML validation and 
extensibility seem to be in conflict due to clash.

Perhaps the schema should define a token similar to the <any> element or 
<anyattribute> that we are using in other drafts, but then we are in a 
situation where we declare that an element can take values 1, 2 or 3, or 
any other... Sounds weird... We either leave the element as a sequence 
of defined tokens and we don't allow IANA registration, or we define the 
element as a "string" type and we don't need IANA registration. In the 
sake of interoperability I will support the former.

- I miss some linkage between PIDF and RPID as a first paragraph in the 
Introduction section. Basically I would like to see: RPID documents are 
extended PIDF documents, therefore, the content type is 
application/pidf+xml. Something like:

    "And RPID document is a PIDF XML document [7] that contains the 
extensions defined by this RFC. Since an RPID document is, in essence, 
an extended PIDF document, it inherits the content type from [7], namely 
application/pidf+xml.

- I am missing the typical XML disclosure text indicating the the 
document is valid and should be well-formed. I suggest to add somewhere 
something on the following lines:

    "An RPID document is an extended PIDF XML document [7] that MUST be
    well-formed and SHOULD be valid. RPID documents MUST
    be based on XML 1.0 and MUST be encoded using UTF-8."

- The current definition of <class> is obscure, since the defined term 
is part of the definition. Additionally, <class> is an element, not an 
attribute:

"The 'class' attribute describes the class of the tuple."
              ^^^^^^^^^
    I suggest something like: "The <class> element provides a mechanism 
for the presentity to group different tuples into a set that are 
identified by a common class type. This information can be used, e.g., 
to provide filtering or authorization based on the whole set (the class) 
rather than the individual tuples. The naming of classes is left to the 
presentity.

- Section 4.2:

     "The <activities> element can be extended by adding elements from 
other namespaces, e.g., to reflect activities appropriate for a 
particular occupation."

     However, the <activities> element does not offer extensibility in 
the schema. If the above is true, the schema should include:

     <xs:any namespace="##other" processContents="lax"
             minOccurs="0" maxOccurs="unbounded"/>

- The conventions should be consistent across the document. For 
instance, I would use <> to name elements, double quotes (") to name 
values, and perhaps single quotes (') to name attributes. If this is 
acceptable, then:

   s/'timestamp'/<timestamp>
   s/'placetype'/<placetype>
   s/'class'/<class>
   s/'privacy'/<privacy>
   s/lt;relationship>/<relationship>
   s/'service'/"service"
   s/'presentity'/"presentity"
   s/'device'/"device"
   s/'idle'/<idle>
   s/'in-person/"in-person"
   s/'street'/"street"
   s/'public-transport'/"public-transport"
   s/'aircraft'/"aircraft"
   s/'ship'/"ship"
   s/'bus'/"bus"
   s/'train'/"train"
   s/'airport'/"airport"
   s/'mall'/"mall"
   s/'outdoors'/"outdoors"
   s/'scouting'/"scouting"
   s/'work'/"work"
   s/'home'/"home"

- Section 4.4:

    "The <contact-type> element describes the type of the tuple."

    So if it is the type of tuple, shouldn't then <tuple-type> be a more 
representative name for this element?

-  Section 4.4: make a reference to the IANA registration section 
(Section 7.5) for extensibility.

- Section 4.7 does not indicate that the initial set of values can be 
increased through the IANA registration process indicated in Section 7.5

- Example in Section 5. The <ep:relationship> element apparently belongs 
to the "rpid-status" namespace, however the schema definition allocates 
this element as part of the rpid-tuple (Section 6.1). So one or the 
other has to change.

- Section 7, first paragraph mentions the registry for 
s/activiy/<activity>, s/place type/<placetype> and 
s/relationshtips/<relationship> but fails to mention <contact-type> 
(Section 4.4) and <privacy> (Section 4.7)

- Similarly, section 7.5 fails to mention the registry for <activity> 
(Section 4.2)

- The references 10, 12, 13, and 14 are never referred from the text. 
You can safely delete them.

Regards,

      Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 12 May 2004 16:24:50 +0300

Henning:

- Section 4.2:

- Section 4.4:

Regards,

      Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 13 May 2004 14:28:36 +0300

I have revised the working version of the cipid-02 draft and it is fine 
to me, with the exception of adding the typical desclaimer about the 
terminology (meaning of MUST, SHOULD, etc.) that includes the pointer to 
RFC 2119.

Other than that, the drafat looks good.

- Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 13 May 2004 14:28:36 +0300

- Miguel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 15 May 2004 14:34:57 -0400

inline.

> extensibility seem to be in conflict due to clash.

In this case, yes. The schema as defined will not allow for extensibility.

> sake of interoperability I will support the former.

There is a middle ground, which is something we've used in the 
authorization work, which is substitution groups. The idea would be to 
define, for example, the activity element this way:

<xs:element name="activity" minOccurs="0">
            <xs:complexType>
              <xs:sequence>
                <xs:element ref="ts:activity-value"
                  minOccurs="1" maxOccurs="1"/>
              </xs:sequence>
            </xs:complexType>
          </xs:element>

Then, each activity element is defined as belonging to this substitution 
group:

<xs:element name="on-the-phone" substitutionGroup="ts:activity-value"/>

An instance document would then look like:

<activity>
   <on-the-phone/>
</activity>

This would allow for us to make it clear what the allowed values are for 
activity, but also allow for extensions that could explicitly define new 
values for activity, within different namespaces even (which I also 
think is a good thing). It would also allow for structured values for 
idle, in case something more than a string was needed.

I'm not sure if this has been discussed or proposed in the past. I 
recognize its a major change in syntax at this point, but it has some 
nice properties and is worth entertaining.

> an extended PIDF document, it inherits the content type from [7], namely 

I would even avoid the term "RPID document" altogether. Its a PIDF 
document extended with rich presence information data.

>    be based on XML 1.0 and MUST be encoded using UTF-8."

THis is not needed if you dont think RPID is a document format.

> "The 'class' attribute describes the class of the tuple."

This is a good point, and something that all folks who write 
xml-oriented documents should keep in mind - be very careful with 
terminology!

> identified by a common class type.

Yeah, but you still repeat the term "class" in the definition.

  This information can be used, e.g.,
>             minOccurs="0" maxOccurs="unbounded"/>

See above for an alternative.

> values, and perhaps single quotes (') to name attributes. If this is 

This is a great point, something that again is applicable to all XML 
oriented documents.

-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: Sat, 15 May 2004 14:34:57 -0400

inline.

<activity>
   <on-the-phone/>
</activity>

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 May 2004 20:26:10 -0400

[Changing subject to be more meaningful.]

> nice properties and is worth entertaining.

I think this is the cleanest of the options that I have seen so far, as 
it makes it easy to define new schema documents that register new values.

Having no extensibility would seem to lead to have to add new artificial 
description elements and just using strings removes the useful mechanism 
of schema verification and documentation. Realistically, I don't see all 
that many extensions, simply because any extension requires translation 
into different languages, icons, user interface selectors, etc.

I plan to proceed as Jonathan suggested; if somebody objects, please do 
so soon.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 May 2004 20:26:10 -0400

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 May 2004 21:48:49 -0400

I can't make the schema validate; any schema hints are most welcome:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
targetNamespace="urn:ietf:params:xml:ns:pidf:status:rpid-status" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmnls:ts="urn:ietf:params:xml:ns:pidf:status:rpid-status" 
elementFormDefault="qualified" attributeFormDefault="unqualified">
   <xs:import namespace="http://www.w3.org/XML/1998/namespace" 
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xs:annotation>
     <xs:documentation xml:lang="en">
     Describes RPID status extensions for PIDF.
     </xs:documentation>
   </xs:annotation>
   <xs:element name="activity">
     <xs:complexType>
       <xs:sequence>
         <xs:element ref="ts:foo"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>
   <xs:element name="phone" substitutionGroup="ts:foo"/>
</xs:schema>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 May 2004 21:48:49 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 May 2004 22:30:17 -0400

I'm skipping the extensibility issues, since this needs mainly schema 
work. Thus, the example in the current revision is still incorrect. 
Comments inline.

>    be based on XML 1.0 and MUST be encoded using UTF-8."

I'm avoiding the RPID=document wording, so since this is just a PIDF 
document, the PIDF wording applies.

> rather than the individual tuples. The naming of classes is left to the 

Reworded.

> values, and perhaps single quotes (') to name attributes. If this is 

I think I got most of them, but if you find any stragglers, let me know.

> representative name for this element?

Indeed.

> this element as part of the rpid-tuple (Section 6.1). So one or the 

Describes a tuple.

> - Similarly, section 7.5 fails to mention the registry for <activity> 

Fixed.

> You can safely delete them.

Left over from older version; removed.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 May 2004 22:30:17 -0400

Reworded.

Indeed.

Describes a tuple.

Fixed.