Re: [apps-discuss] Apps-team review of draft-ietf-xcon-common-data-model-25.txt

Oscar Novo <> Tue, 19 April 2011 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 688DCE06DB for <>; Tue, 19 Apr 2011 05:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fi9CCsc4muo1 for <>; Tue, 19 Apr 2011 05:16:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F07E5E00BE for <>; Tue, 19 Apr 2011 05:16:53 -0700 (PDT)
X-AuditID: c1b4fb3d-b7bd5ae000002ba3-bd-4dad7d34ca9a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id ED.CE.11171.43D7DAD4; Tue, 19 Apr 2011 14:16:53 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 19 Apr 2011 14:16:53 +0200
From: Oscar Novo <>
To: Tim Bray <>, "" <>, "" <>, S Moonesamy <>, "" <>, Gonzalo Camarillo <>, "" <>, "" <>
Date: Tue, 19 Apr 2011 14:16:52 +0200
Thread-Topic: Apps-team review of draft-ietf-xcon-common-data-model-25.txt
Thread-Index: Acv8W8+FeEf6SU4NReuOnE5ER3Aw6QCKYAfQ
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Tue, 19 Apr 2011 08:08:07 -0700
Subject: Re: [apps-discuss] Apps-team review of draft-ietf-xcon-common-data-model-25.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Apr 2011 12:16:55 -0000

Hi Tim,

I've created a new version of the draft with your comments:

My comments inline as a [ON]



-----Original Message-----
From: Tim Bray [] 
Sent: 16. huhtikuuta 2011 20:29
To:;; S Moonesamy;; Oscar Novo; Gonzalo Camarillo;;
Subject: Apps-team review of draft-ietf-xcon-common-data-model-25.txt

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see

I'm not a strong enough SIP expert to express an opinion as to whether this is ready for publication in the sense of it being a useful and problem-free extension of the SIP standards framework.  However, it seems a reasonable specification of a reasonable XML language extension and I didn't see anything obviously broken at the SIP level; there are a few nits, noted below, that should be addressed:

Observation: Element names given in double quotes, attribute names in single quotes.  Odd.  Is this a convention?

[ON] That's only a way to facilitate the reader a better understanding of the documents. 

General issue: There is much discussion of the values of various elements.  There seems little discussion of whether exact case matching is required, whether white-space on either side of the designated values is allowed, and so on.  Is this obvious from the context of the other SIP RFCs?  It would trouble me as an implementor.
 There are a couple of nits below where I've called this out.

[ON] The RELAX NG shema is defining the syntactic of the elements. That's why the text is not giving any clear guidance about it. The implementor just has to follow the RELAX NG schema defined in this document. 

Apology in advance: There are quite likely things I've called out that would be obvious to a seasoned SIP implementor who is after all the target of this draft; pardon the irritation.


1. 3rd para "specifies by whom, and in which way that information" - needs comma after 'way'


3.4 "defined in the data model" is unclear. You mean "the data model in this specification" I think? But I'm not sure.


4.1 " A conference object document begins with the root element tag <conference-info>" - the word 'tag' is superfluous here, not part of the idiom used elsewhere in this document


4.2 <conference-description> takes a "lang" attribute.  Is this free text, ISO 639, or takes its definition from elsewhere in the SIP suite?  Shouldn't something be said?

[ON] the precise type of the attribute is defined in the RELAX NG Schema. It would be redundant to mention it in the text. 

4.2.6  "The <allow-sidebars> element represents a boolean value.  If set to  TRUE" Does this mean the content of the element must be the string TRUE?  Case-sensitive?  White-space before and after allowed?

[ON] The type of <allow-sidebars> is defined in the RELAX NG schema as a boolean value. The implementor should follow the XML rules to define it. 

4.2.9 2nd bullet - 'This attribute contains one of the following
values: "none", "administrator", "moderator",  "user", "observer", and "participant". '  Is it obvious to a reader whether exact-matching is required or case-mixing is allowed? Is white space allowed?  Apologies if this is defined elsewhere and I missed it.

[ON] The RELAX NG schema defined the type of this attribute in the single-role-type element. An implementor should follow the exact syntactic format defined in this attribute. 

4.2.9 2nd bullet - " The roles semantic" - missing apostrophe after "roles".  Also grammatically awkward, maybe "The roles' semantic definitions are.."


4.2.9 3rd bullet - "The <mixing-end-offset> child element specifies the time a conference media mixing stops" - superfluous "a" after "time"


4.2.13 4th bullet - missing comma after "values"


4.4.1 "The <allow-conference-event-subscription> element represents a boolean action. " - should 'action' be 'value'? (this idiom also appears several more times in the draft)

[ON] I would say it's right. The element represents a boolean action. That's mean, the action can only take two boolean values. 

4.5 " Other elements from different namespaces MAY be present for the purposes of extensibility." I was a bit surprised to encounter this for the first time here; does such extensibility not apply to all the elements defined previously? If it's generally true, maybe move it up
to an introductory section?   If child namespaces are generally
disallowed and this is an exception, that also deserves saying at the top of the document.  Section 6 suggests that extensibility is generally allowed for elements in this language, in which case the statement here is superfluous?

[ON] Right, I've removed it from that section. It creates unclarity and confision in this part of the text. As you point out, section 6 explains the extensibility of the elements. 

4.6.2 ""closedAuthenticated": A 'closedAuthenticated' policy MUST have  each conference participant in the allowed users list (listed under the <allowed-users-list> XML element" - 'XML' is superfluous, appears a couple of times in this section


4.6.5 "4.6.5.  <user> and Its <user> Sub-elements" - title looks funny, is the second <user> superfluous?

[ON] This document extends RFC4575. The name of that section comes from it:

8. "Futhermore, users may use different namespaces to access to a conference as explained in Section 4.6.5."  I revisited 4.6.5 and it doesn't contain the word "namespace", it discusses user identifiers.
Should "namespace" be replaced by "identifier" in this paragraph?
Also "Futhermore" is misspelled.