Re: [Crisp] Last Call Comments on common-transport-03

Andrew Newton <> Wed, 23 August 2006 13:54 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GFtBc-0000gb-J7; Wed, 23 Aug 2006 09:54:28 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GFtBb-0000ei-HD; Wed, 23 Aug 2006 09:54:27 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GFtBa-0007ZR-9t; Wed, 23 Aug 2006 09:54:27 -0400
Received: from [] ([::ffff:]) (AUTH: LOGIN anewton) by with esmtp; Wed, 23 Aug 2006 09:54:17 -0400 id 0158819C.44EC5E09.00004204
Message-ID: <>
Date: Wed, 23 Aug 2006 09:54:12 -0400
From: Andrew Newton <>
User-Agent: Thunderbird (Windows/20060719)
MIME-Version: 1.0
To: Marcos Sanz/Denic <>
Subject: Re: [Crisp] Last Call Comments on common-transport-03
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Marcos Sanz/Denic wrote:
> Section 3: On the use of attribute "language" for all <description>: RFC 
> 3470 strongly recommends to use the attribute "xml:lang" for these 
> purposes instead.

Considering that both the reference for the 'language' datatype in XML 
Schema and the definition of the values for xml:lang in XML 1.0 both point 
back to RFC 3066, these are functionally equivalent.  This is really just a 
difference in style.  The guidance in 3470 is to use such a feature, 
xml:lang explicitly being mentioned in the case of DTDs.

> Section 3: Wouldn't it be more compact to have a <authenticationResult> 
> instead of two sepparate elements for one semantic? Then 
> <authenticationResult> would have a child choice between <success/> and 
> <failure/> (together with the potential <description> children). This is 
> just optimization, I really don't care much about this.

I'm not sure how it would be more compact because your suggestion adds an 
element.  Again, this is a difference in style.  It should also be noted 
that XPC defines the authentication success and authentication failure 
chunks as two different types.

> Section 3: Why is the attribute protocolId of type "token", but the other 
> Ids (extensionIds, authenticationIds) are "normalizedString"? I know that 
> the only difference is the whitespace collapsing, I just want to know if 
> there's some deeper meaning behind that.

There is no deep meaning other than lack of consistency.  Which do you 
prefer, token or normalizedString?

> Section 4: Seeing the comments on the lwz draft in the general IETF 
> mailing list, I don't know if it's fortunate to list dreg1 in the example 
> as being transported over iris.lwz

LWZ existed before XPC.  If this is a big deal, we can change it.

> Typos/Formulation:
> Section 1: s/specifed/specified/
> Section 1: s/comforant/conformant/
> Section 4: s/Each of these element types/Each of these element types 
> (except <versions>)/
> Section 4: s/optionalal/optional/
> Section 4: s/identifers/identifiers/
> Section 4: s/transfered/transferred/
> Section 4: s/transfer of data is counted/transfer of data could be 
> counted/
> And the actualization/corrections of the references section, but this has 
> already been mentioned for the lwz draft in the general list.



Crisp mailing list