Subject: [Sipping] RE: URIs in conference event package.

From: "Orit Levin" <[email-masked]>
Date: Wed, 17 Nov 2004 11:42:14 -0800

I think that it is a good proposal.

One comment: among other comments that I received, I am planning to
remove the <web-page> element and instead to add a text suggesting that
the "web-page" case falls under one of the <service-uris> with value to
be registered with IANA: "web-page".

Orit. 

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Wednesday, November 17, 2004 3:50 AM
> To: Jonathan Rosenberg; Henning Schulzrinne; Orit Levin; sipping
> Subject: URIs in conference event package.
> 
> 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: "Orit Levin" <[email-masked]>
Date: Tue, 30 Nov 2004 12:44:54 -0800

To complete the "poll", I am including the "IANA Consideration" text
proposed by Miguel in earlier email exchanges (with slight editorial
changes). Please review the text.

If I don't hear any opposition in the following two days, I will include
the text, remove the currently "stand-alone" recording element from the
schema, and resubmit it as -08.

Thanks a lot,
Orit.

-------------

This document instructs IANA to open a new "purpose of URI" sub-registry
under the registry of SIP parameters
(http://www.iana.org/assignments/sip-parameters):

       purpose of URI

The purpose of URI is an XML element encoded in the conference event
package (draft-ietf-sipping-conference-package). The value of the
<purpose> element indicates the intended purpose of an associated URI.

This sub-registry is defined as a table that contains three columns:

Value: the token under registration.

Description: A descriptive text that indicates what is the intended
usage of the URI.

Document: A reference to the document defining the registration.

This specification instructs IANA to create this table with an initial
entry.  The resulting table would look like:

Value         Description                                   Document
-------       --------------------------------------------  ----------

participation The URI can be used to join the conference    [RFC XXXX]
streaming     The URI can be used to access the streamed    [RFC XXXX]
              conference data   
event         The URI can be used to subscribe to the       [RFC XXXX]
              conference event package
recording     The URI can be used to access the recorded    [RFC XXXX]
              conference data
web-page      The URI can be used to access a web page      [RFC XXXX]
              that contains additional information of
              the conference

New values of the purpose of URI are registered by the IANA when a
specification becomes available, according to the definition of
Specification Required in RFC 2434. The IANA Considerations section of
the specification must include the following information, which appears
in the IANA registry along with the specification of the publication:

Value: the value of the <purpose> element to be registered.
Description: a short description of the intended usage of the URI.
------------- 

> Sent: Tuesday, November 30, 2004 11:18 AM
> To: sipping
> Cc: Alan Johnston; Orit Levin
> Subject: Re: [Sipping] URIs in conference event package.
> 
> 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
> 
> 
> Miguel Garcia wrote:
> 
> > On reviewing the conference event package, I found several places 
> > where URIs try to represent different aspects of the conference.
> > 
> 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. 
> 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.
> > 
> 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).
> > 
> uris (sip 
> > and tel URLs), a CPCP URI and a web page:
> > 
> > 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 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:
> > - conference-event: not required, just for completeness. URL to 
> > subscribe to the conference event package of this conference.
> 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
> 
> --