Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt

From: [email-masked]
Date: Mon, 25 Jan 2010 18:30:53 +0100

Hi Sean,

sorry for the delay in answering your comments. Please find inline our  
answers to your new questions ([spromano] prepended).

As to the issues associated with the "<conference-password>" field:

> [SEAN]: Actually you are right this is a data model issue, however   
> since we have started the question we might as well finish it here....
> I don't think this has anything to do with RBAC etc. The new   
> <xcon:conference-password> field was introduced to specify a   
> password for a conference. My question is:- If a conference has two   
> passwords, one for moderator and one for particpant, how would a   
> (CCMP) client know which one is the moderator and which one is the   
> conferee?

[spromano] As I said, in the data model such scenario is not envisaged  
(i.e. there are no role-related passwords per conference object). I  
think we should discuss this with Oscar and the other authors of the  
data model if you see a need for this.

As to the "filters" issue:

> [SEAN] XPATH definietly will work and covers all filter   
> possibilities. However, should the draft state that a server could   
> only support a limited,documented set of xpath queries?
> Support for a complete range of xpath queries would/could be   
> difficult to implement ....

[spromano] Yes. I think we should definitely take your advice. A  
minimal set of xpath queries should be considered as mandatory for any  
CCMP-compliant server. We were thinking of things like "conference  
state" (active, registered, etc.),  conference participants,  
conference media (info about all media involved in a conference), and  
the like. Do you have any other clue on this?

Finally, as to the "ambiguity" issue:

> [SEAN] My concern here is that this introduces ambiguity. If a   
> conference-type element is returned with no <users> element, does   
> that imply the conference does not have any users Or the server   
> didn't bother populating this element?

[spromano] What I meant here was that, in general, a conference server  
should return to a client the "most complete" set of information it  
has available, i.e. all data requested by the client and for which the  
client itself holds an access right. This means that, in the absence  
of server-side policies, each and every query would be answered with  
the complete conference document.

Cheers,

Simon

P.S.
More mails are following, related to your further comments...

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jan 2010 12:38:17 -0500

> minimal set of xpath queries should be considered as mandatory for  
> any CCMP-compliant server. We were thinking of things like  
> "conference state" (active, registered, etc.),  conference  
> participants, conference media (info about all media involved in a  
> conference), and the like. Do you have any other clue on this?

It's not clear to me how using a subset of XPath queries creates any  
benefit here.  There are several XPath libraries out there that cover  
the complete spec, so it's not hard for CCMP implementations can get  
full XPath by using one of them.  And the alternatives seem  
undesirable, e.g., matching against fixed XPath literals or hacking up  
some incomplete implementation of XPath.

I would recommend leaving the document as-is.

--Richard

---

From: [email-masked]
Date: Mon, 25 Jan 2010 20:06:03 +0100

Hi Richard,

we're fine with this.

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 26 Jan 2010 10:58:17 -0000

Yes there are many xpath libraries out there which work fine if the CCMP server has its conferences stored in a XML database. 
However the majority of CCMP implementations I would imagine would be backed by some sort of RDBMS along with other internal components which means 
the implementor must convert all the conference data to xml and then apply the XPATH filter.... This wont perform on a large conferencing system

All I am suggesting is that the spec allows for the possibility of some implementations supporting a subset of xpath filters and if a xpath filter
is passed down that is not supported an exception is thrown...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 25 January 2010 19:06
To: Richard L. Barnes
Cc: Duddy, Sean (Sean); [email-masked]
Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-04.txt

Hi Richard,

we're fine with this.

Simon