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
- [Crisp] Last Call Comments on common-transport-03 Marcos Sanz/Denic
- Re: [Crisp] Last Call Comments on common-transpor… Andrew Newton
- Re: [Crisp] Last Call Comments on common-transpor… Marcos Sanz/Denic
- Re: [Crisp] Last Call Comments on common-transpor… Andrew Newton
- Re: [Crisp] Last Call Comments on common-transpor… Hollenbeck, Scott
- Re: [Crisp] Last Call Comments on common-transpor… Andrew Newton
- Re: [Crisp] Last Call Comments on common-transpor… Hollenbeck, Scott
- Re: [Crisp] Last Call Comments on common-transpor… Andrew Newton
- Re: [Crisp] Last Call Comments on common-transpor… Hollenbeck, Scott