Subject: [Sipping] URIs in conference event package.

From: Miguel Garcia <[email-masked]>
Date: Wed, 17 Nov 2004 13:49:53 +0200

On reviewing the conference event package, I found several places where 
URIs try to represent different aspects of the conference.

Specifically, the current event package defines these three types of 
URIs within the <conference-description> element:

<web-page>
<conf-uris>
<service-uris>

The <web-page> element is clear, it is just a displayable web page URI. 
The <conf-uris> is also clear, is just a URI where a participant can 
join the conference.
The <service-uris> is tricky. It pretends to be a URI that gives you 
access to other "things", such as CPCP, or MPCP, or access rules. 
However, there are no semantics associated with this element, so the 
software can only display this information to the user, and let him take 
an action about that URI.

I think this can be improved by having some automatic way of indicating 
to the software what is the purpose of a URI. Also, I think we can group 
all these URIs in a single element that contains a number of entries. 
The idea: a single <uris> element that includes one or more <entry> 
elements, which include a <uri> and a new <purpose> elements that 
indicate what is the purpose of that URI. The <purpose> element contains 
a token, such as "conference" (the actual conference uri), "information" 
(e.g., web page), "cpcp" (uri to do cpcp), "mpcp" (uri to do mpcp), 
"conference-event" (the actual uri to subscribe to this package) , 
"floor-control", "sidebars" or any other token that is required.

If we follow this scheme, there is no need for 3 different elements 
anymore, just one. And we get a standardized <purpose> element, so the 
software can get the information of where to do the appropriate action 
(e.g., start a floor control session).

An example of my proposal, including a couple of conference uris (sip 
and tel URLs), a CPCP URI and a web page:

<conference-info entity="sips:[email-masked]" state="partial" 
version="5" >
  <conference-description>
    <subject>Agenda: This month's target</subject>
    <uris>
      <entry>
        <uri>sip:[email-masked]</uri>
        <purpose>conference</purpose>
      </entry>

      <entry>
        <uri>tel:+1-555-7777</uri>
        <purpose>conference</purpose>
      </entry>

      <entry>
        <uri>http://salesgroup.example.com/policies/meeting.xml</uri>
        <purpose>cpcp</purpose>
      </entry>

      <entry>
        <uri>http://info.example.com/conf/conf32.html</uri>
        <purpose>information</purpose>
      </entry>
   </uris>
</conference-description>

In my opinion, this is elegant and precise. The only drawback is that 
this requires to open an IANA registration for values of the <purpose> 
elements of URIs, but I don't see a big issue with this. It also 
requires to allocate semantics to each of these tokens.

The relevant part of the XML schema will look like this:

      <!--
        CONFERENCE URI TYPE
      -->
      <xs:complexType name="uri-type">
        <xs:sequence>
           <xs:element name="uri" type="xs:anyURI"/>
           <xs:element name="label" type="xs:string" minOccurs="0"/>
           <xs:element name="purpose" type="xs:string"
                       maxOccurs="unbounded"/>
           <xs:element name="modified" type="execution-type"
                       minOccurs="0"/>
           <xs:element name="extended" type="extended-type" minOccurs="0"
                       maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute/>
      </xs:complexType>

The draft will also need to open an IANA registry for the values of the 
<purpose> element in this XML document. The initial values could be:
- information: web page containing additional conference information
- cpcp: URL to do CPCP actions
- mpcp: URL to do MPCP actions (if MPCP requires URLs)
- floor-control: URL to initiate a floor-control session
- conference-event: not required, just for completeness. URL to 
subscribe to the conference event package of this conference.
- access-rules? Is this one needed

One thing, though: I first thought about using substitution groups in 
the XML schema, but due to the discussion in SIMPLE about how to create 
extensible tokens, I believe the IANA registry and a text string is what 
we are looking for. But we should apply the same output as in SIMPLE 
documents.

But in essence, what is the feeling of the working group about this 
proposal?

Regards,

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 30 Nov 2004 21:17:56 +0200

Hi:

A few days ago I submitted some comments to the conference event 
package. I was proposing to add a <purpose> element to a uri <entry>, so 
that it was possible to describe what service is behind that URI. The 
idea I had in mind is that my UA can receive a notification of the 
conference event package and my UA can automatically do certain actions, 
such as establishing a cpcp session or opening a web browser to display 
extra information.

To do this, we don't only need to add a <purpose> element, but we need 
to list a collection of values and the semantics associated to them. For 
instance, the focus needs to indicate "this is the URI where you can 
initiate a BFCP session"; then my UA can initiate a BFCP session if it 
is able to do it.

So the point is that we need to list the different values that the 
<purpose> element can take, otherwise, different focus can encode 
different values, and UAs will not be able to interpret them.

Further more, it is clear that we need extensibility, since there are 
protocols associated to a conference that are still under development.

Having an extensible list of possible values defined in the XML schema 
is hard, as it has been discussed in SIMPLE. Therefore, my 
recommendation was to define the <purpose> element as a string, and open 
an IANA registration of values. Each value will indicate the purpose of 
this URI and perhaps the protocol that can be used to access it.

I would like to know if the working group would have a problem if the 
conference package adds a <purpose> element in the URI <entry> 
definition, the values of <purpose> will be registered with IANA.

Regards,

             Miguel