Subject: RE: [Sipping] WGLC Summary for draft-ietf-sipping-conference-pack age-06

From: "Johnston, Alan" <[email-masked]>
Date: Wed, 24 Nov 2004 22:36:37 +0000

Miguel,

See my comments below.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Miguel Garcia
> Sent: Wednesday, November 24, 2004 9:03 AM
> To: Orit Levin
> Cc: sipping; Henning Schulzrinne
> Subject: Re: [Sipping] WGLC Summary for 
> draft-ietf-sipping-conference-package-06
> 
> 
> Hi:
> 
> Some comments on two of the not-agreed issues:
> 
> Orit Levin wrote:
> 
> >  
> >    o  Merge the conf-uris and service-uris under the same element 
> > (they
> > clearly mean different things).
> 
> I agree that these URIs clearly mean different things, but we 
> have the 
> <purpose> element exactly to differentiate their means, so I 
> don't think 
> there is a need to do further differentiation into <service-uris> and 
> <conf-uris>. This is more a aesthetic issue, since it doesn't have an 
> inpact on the functionality.

I oppose putting them together since conference URIs have extremely clear
semantics, and are going to be parsed and used by UAs in call control
operations (INVITEs, REFERs, etc.).  Service URIs, on the other hand, really
don't have any semantics right now - they would just be rendered to the
user.  I would expect most UAs to simply ignore Service URIs until we add
semantics in XCON.

Lets keep them separate as they are now.

> 
> 
> >    o  Add the "purpose" element to the "uri-type" and register with 
> > IANA
> > the "purpose" values used with "service-uris" (leave this 
> job to XCON)
> > 
> 
> The <uri-type> will contain the <purpose> element, since this 
> type will 
> be used by any kind of URI. So, if I understand correctly, you don't 
> want to register with IANA the possible values that will indicate 
> additional services (e.g., CPCP, MPCP, ... you name it). If 
> this is the 
> case, I have no problem with this approach. We just need to make sure 
> that the protocols in XCON (CPCP, MPCP), etc. will register with IANA 
> the token in the <purpose> element of the conference event package.

I agree that we will likely need to set up some IANA registries for elements
in the conference package.  However, I'd rather do it once in XCON than do
it now (when we have only one field, and only one value to register), then
go back to IANA again in 6 months and do it all again.  Lets save work and
do it only once.

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

_______________________________________________
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: Thu, 25 Nov 2004 09:47:50 +0200

Alan, I don't quite agree with you. Let me see if we are all speaking 
about the same thing.

On one side, we have an issue related to how to assign semantics to a 
URI. The idea is that the focus can include a URI indicating what can 
the UA do with that URI. For instance, the focus can say: here is the 
URI that you can use to join this conference (and can be a sip, h323, 
tel or alike URI). Another example is the URI that a UA can use to do 
CPCP operations, get a web page information, etc.

Is there a commonality among all of them: In my opinion, yes, there is 
one: all are URIs and we need to indicate what can the UA do with this 
URI, that is the <purpose> element.

With this approach in the conference event package, one can design a 
smart UA, that subscribe to the conference event package, and gets a 
collection of URIs where the UA can start a CPCP session, floor control, 
etc. You name it. Everything is automatic because the URI indicates its 
purpose, and the values of these purposes are well known tokens 
registered with IANA.

In this model there is no need to distinguish <service-uris> from 
<conference-uris>, because that distinction is provided by the <purpose> 
element that comes together with the <uri> element. All of them are a 
bunch of uris with a specific purpose. And the semantics are clear 
through this <purpose> element.

I hope we can agree on the above. If we do, then we need to solve 
another issue: how do we move forward from where we are today to the 
above described scenario. What we need to do today is to open the IANA 
registry for the values of <purpose> element. Today we can register 
tokens for "conference" (what we call so far conference-uris) and 
"web-page". Perhaps "recording" as well (the uri of the recorded 
session). I agree we don't need to register other purpose for other 
actions that are still under discussion in XCON (I am referring to CPCP, 
  MPCP, floor control, etc.). This can be done by the respective 
CPCP/MPCP/BFCP drafts, if/when required).

BR,

       Miguel