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

Marcos Sanz/Denic <sanz@denic.de> Wed, 23 August 2006 14:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtlU-0007ZL-T8; Wed, 23 Aug 2006 10:31:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtlT-0007WC-D0 for crisp@ietf.org; Wed, 23 Aug 2006 10:31:31 -0400
Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtlR-0008Cz-27 for crisp@ietf.org; Wed, 23 Aug 2006 10:31:31 -0400
Received: from notes.rz.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1GFtlO-0001VP-A3; Wed, 23 Aug 2006 16:31:26 +0200
In-Reply-To: <44EC5E04.3000204@hxr.us>
To: Andrew Newton <andy@hxr.us>
Subject: Re: [Crisp] Last Call Comments on common-transport-03
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
From: Marcos Sanz/Denic <sanz@denic.de>
Message-ID: <OF5E4BCD8F.8CEFC6CC-ONC12571D3.004D6CC5-C12571D3.004FC4BC@notes.denic.de>
Date: Wed, 23 Aug 2006 16:31:17 +0200
X-MIMETrack: Serialize by Router on notes/Denic at 23.08.2006 16:31:26, Serialize complete at 23.08.2006 16:31:26
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: crisp@ietf.org, iesg@ietf.org
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org

Hi Andy,

> 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.

Absolutely, the semantics it's the same. The point is whether we need to 
introduce a new attribute and its definition, or we can resort to one 
which is already embedded in the XML specification. I'd prefer the latter.
For me, 3470 strongly recommends to use xml:lang in any case, not only for 
DTDs, but we can ask the XML directorate about my interpretation. Hmmm... 
wait a moment! You are a member of the XML directorate! :-)

> > 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.

Yes, I've started reading XPC that after that I sent the mail. Let's leave 
it like it is now.

> > 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?

The first question is: Should identifiers be allowed to contain 
whitespace? I don't see a reason for banning them, they are like any other 
characters. Common-transport states that the identifiers are of no 
specific type and explicitly states it will define none. Further: one of 
the examples contains a whitespace in the autenticationId and URLs can 
contain spaces.

So let's keep spaces in it. But if they are like any other characters and 
common-transport doesn't want to define a specific type of them, why 
should

"PLAIN EXTERNAL" match "PLAIN   EXTERNAL"

? It seems then to me that whitespace collapsing is not a wished feature, 
and would tend to use 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.

No, not really a big deal.

Best regards,
Marcos

_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp