Subject: [XCON] Comments on draft-ietf-xcon-ccmp-05

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Wed, 3 Feb 2010 11:04:10 -0000

Hi All,
	There is a contradiction in section :-

7.7.  Alice adds a new user to the conference

The text preceeding the call flow indicates that the response should
contain the confUserID of the newly added participant. However the
example
shows the confUserID is constant for the transaction i.e. 'Alice'. In my
opinion, the text is wrong and needs to change.

On a genral note, should we have CCMP examples in both the ccmp draft
and in the new examples draft? Personally I think the examples should be
in one doc only.

Sean

---

From: Oscar Novo <[email-masked]>
Date: Wed, 3 Feb 2010 16:11:16 +0100

Hi Sean,

In this case the '*' is right. Elements with a '*' are extensions in the data model. 

Cheers,

Oscar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Duddy, Sean (Sean)
Sent: 22. tammikuuta 2010 14:18
To: [email-masked]
Subject: [XCON] Comments on draft-ietf-xcon-common-data-model-14

Minor change:

In section 4, there is an '*' after the <conference-time> element indicating that this element has been defined in rfc4575. 
This '*' should be removed because <conference-time> is a new extension defined in this model...

Sean
_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

---

From: Oscar Novo <[email-masked]>
Date: Wed, 3 Feb 2010 16:11:23 +0100

Hi,

Thanks for the note. I'll fix it in the next version.

Oscar 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Duddy, Sean (Sean)
Sent: 22. tammikuuta 2010 17:48
To: [email-masked]
Subject: [XCON] Comments on draft-ietf-xcon-common-data-model-14

Hi,
	
The elements

    <xs:element name="cloning-parent" type="xs:unsignedLong"/>
    <xs:element name="sidebar-parent" type="xs:unsignedLong"/>

Have the wrong type, they should have type "xs:anyURI"

Sean

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Thu, 4 Feb 2010 16:56:44 -0000

Hi All,
	I think we need a response code for requests that contain valid
xml but certain elements/value(s) are incorrect
or are simply not supported by the CCMP server implementation. 

Maybe a response code of notSupported or something like that?

On a previous email I outlined also that we are missing an
ObjectAlreadyExists response code.
		
On a separate issue, do you think the CCMP requests should have the
ability to store ANYs also?
i.e. adding it to ccmp-request-message-type? I don't have a use case for
it now but I think there is no harm having
the possibility to allow clients specify custom parameters to
operations. 

Also it might be an idea to facilitate the possibility of specifying new
requests. The CCMP xsd could expose another 
Request/Response pair to faciliate this e.g.

        <xs:complexType name="ccmp-extended-request-message-type">
          <xs:complexContent>
            <xs:extension base="tns:ccmp-request-message-type">
              <xs:sequence>
                <xs:any namespace="##other" processContents="lax"
		         minOccurs="0" maxOccurs="unbounded"/>
              </xs:sequence>
              </xs:extension>
          </xs:complexContent>
        </xs:complexType>

	<xs:complexType name="ccmp-extended-response-message-type">
          <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
              <xs:sequence>
                <xs:any namespace="##other" processContents="lax"
		         minOccurs="0" maxOccurs="unbounded"/>
              </xs:sequence>
            </xs:extension>
          </xs:complexContent>
        </xs:complexType>

Sean

---

From: Mary Barnes <[email-masked]>
Date: Fri, 5 Feb 2010 10:51:56 -0600

Hi guys,

Sorry for the delay in getting into the details of this thread. I have a
couple comments below [MB].

Thanks,
Mary.

On Mon, Jan 25, 2010 at 1:03 PM, <[email-masked]> wrote:

> Hi Sean,
>
>
> Hi All,
>>        I would like some clarification on the use of the
>> <cloning-parent> element with the CCMP protocol.
>> My understanding is that this element is not returned in confResponse
>> where a conference is cloned from a blueprint. Is that correct?
>>
>
> [spromano] Yes, it is.
>
>
>
>> What if I want to clone an existing conference? Would the
>> <cloning-parent> element be returned in the confResponse?
>>
>
> [spromano] Yes.
>
>
>
>> If a conference has a <cloning-parent> element, does that imply that it
>> inherits attributes not specified in its conference object from the
>> parent that is specified by the <cloning parent>?
>>
>
> [spromano] From your comment I derive that you're envisaging a scenario in
> which I can clone a conference by issuing a confRequest/create message
> containing a conference document which explicitely states its will of being
> created as a clone of an existing one. This is done by providing the XCON
> URI of the parent object inside the <cloning-parent> element. Is this right?
> Indeed, the only way to clone a conference object is (see section 5.3 in
> draft-ietf-xcon-examples-02) by sending a confRequest/create message to the
> server, with no conference document attached and with the XCON-URI of the
> object-to-be-cloned in the confObjID parameter. Subsequent updates to such
> new document can be made through confRequest/update messages.
>
> Note that the <cloning-parent> element is created by the server and sent
> back to the client.
>
>
> And if a parent obect
>> is modified, these changes would be applied  to its children also by the
>> server?
>> I recall a while back that it may be possible to specify what attributes
>> can be overridden by a child conference. How is that achieved?
>>
>> Finally, I assume CCMP would support the possibility to break this
>> parent/child relationship, by sending an confRequest update with an
>> empty <cloning-parent> element?
>>
>> I think the ccmp draft needs to add in some more detail and possibly
>> examples for cloning conferences ...
>>
>
>
> [spromano] This part is quite tricky, indeed. Though, this is not related
> to the CCMP. Cloning and associated policies are treated in RFC 5239,
> section 7.1 (Cloning Tree). Our interpretation of such part of the framework
> is that the so-called "parent-enforceable" mechanism is something hidden
> from the clients (i.e. it is a server-specific issue). If this were not the
> case, then the data model should contain a boolean "parent-enforceable"
> attribute for all elements that can be subject to such mechanism, which is
> not the case at this moment.
>
> Do Mary, Oscar and the other authors of the mentioned documents (RFC 5239
> and draft-ietf-xcon-common-data-model) confirm our assumption?
>
[MB] We actually  had this same thread of discussion almost a year ago and I
was asking this same question:
http://www.ietf.org/mail-archive/web/xcon/current/msg02205.html

 I do still believe that the client needs this information. Certainly some
clients won't be able to use it, but I think other more intelligent clients
might.  As I recall, the <cloning-parent> attribute was added based on this
discussion, but I think we still need the independent (or not) attribute.
[/MB]

>
> Thanks again for your invaluable feedback!
>
>
> Simon
>
>
> --
>                            _\\|//_
>                            ( 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: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 9 Feb 2010 18:01:57 -0000

Hi All,
    Thanks for the clarfication on the items below. On the outstanding issues:-
 
    How could we encorporate a 'parent-enforceable' type attribute for the elements already defined in rfc4575? 
E.g it would be very useful to enforce the max conference size(maximum-user-count), which is defined  in rfc4575...
 
I mentioned below that I believe that CCMP protocol would be greatly enhanced if a client could specify a conference doc with specific settings for the conference clone operation.
The typical scenario is, a client wants to use a known blueprint/working conference but obviously wants a different name, that name could be specified in the conf doc supplied in the clone operation.
 
Without this feature, it means two requests are required by the client. Actually a more difficult situation is where clients specify passwords for conferences, so if clone operation doesnt have the ability to
supply new passwords, the CCMP server wont have the passwords for the new conference and cant use the ones from the cloning parent....so what does it do?
 
Sean 

________________________________

From: Mary Barnes [mailto:[email-masked]] 
Sent: 05 February 2010 16:52
To: [email-masked]
Cc: Duddy, Sean (Sean); [email-masked]
Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05

Hi guys,
 
Sorry for the delay in getting into the details of this thread. I have a couple comments below [MB].
 
Thanks,
Mary.

	Hi Sean, 

		Hi All,

	[spromano] Yes, it is. 

	[spromano] Yes. 

	[spromano] From your comment I derive that you're envisaging a scenario in which I can clone a conference by issuing a confRequest/create message containing a conference document which explicitely states its will of being created as a clone of an existing one. This is done by providing the XCON URI of the parent object inside the <cloning-parent> element. Is this right? Indeed, the only way to clone a conference object is (see section 5.3 in draft-ietf-xcon-examples-02) by sending a confRequest/create message to the server, with no conference document attached and with the XCON-URI of the object-to-be-cloned in the confObjID parameter. Subsequent updates to such new document can be made through confRequest/update messages.
	
	Note that the <cloning-parent> element is created by the server and sent back to the client. 

		And if a parent obect

	[spromano] This part is quite tricky, indeed. Though, this is not related to the CCMP. Cloning and associated policies are treated in RFC 5239, section 7.1 (Cloning Tree). Our interpretation of such part of the framework is that the so-called "parent-enforceable" mechanism is something hidden from the clients (i.e. it is a server-specific issue). If this were not the case, then the data model should contain a boolean "parent-enforceable" attribute for all elements that can be subject to such mechanism, which is not the case at this moment.
	
	Do Mary, Oscar and the other authors of the mentioned documents (RFC 5239 and draft-ietf-xcon-common-data-model) confirm our assumption?

[MB] We actually  had this same thread of discussion almost a year ago and I was asking this same question:
http://www.ietf.org/mail-archive/web/xcon/current/msg02205.html
 
 I do still believe that the client needs this information. Certainly some clients won't be able to use it, but I think other more intelligent clients might.  As I recall, the <cloning-parent> attribute was added based on this discussion, but I think we still need the independent (or not) attribute.
[/MB]

	Simon

	
	
	XCON mailing list
	[email-masked]