Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt



I have reviewed the diff of the -10 against the last version I reviewed
in detail (-08) and have just one general question,  a few comments and
one nit. Overall, I think the document is ready to progress.

Regards,
Mary.   

Question:
----------
I did have one general question as to whether this version incorporates
the additional media fields that were identified by the MEDIACTRL folks?


Comments:
---------

S4 and S5: While working on the details for the protocol, I realized we
need a couple more elements added to <conference-description> including
an element to reflect if this conference is a "parent" and/or a "child"
and the "parent" of a "child" conference and the "child"ren of the
"parent" conferences  and whether the "child" is "independent" from the
"parent".   I think we can do that by defining the following:  
- "parent" element that can hold the XCON-URI for the parent and a
boolean as to whether the child is "independent" of the parent. 
- "child" attribute that contains a set of XCON-URIs, one for each child
obviously. 

S4.1/p13, 3rd sentence. For some reason, it is no longer clear to me why
we wouldn't want "state" and "version" as part of the <conference-info>,
as XCON will also support notifications, if I understand this sentence
correctly:
   "Note that the
   <conference-info> element does not have the attributes 'state' and
   'version' defined in [RFC4575] for this element because these
   attributes only applies to notification mechanisms."
   (also note the NIT in that sentence below)

S.4.6.5/p24, 3rd sentence. Same point as above wrt "state". 
   

Nits:
-----

S4.1/p13, 3rd sentence: "applies" -> "apply" 
_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.