[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [KEYPROV] Tentative Conclusion on XML Design Question
I had a brief discussion on this with Tony Nadalin (IBM) last night.
Using HTTP identifiers in protocols is a problem, people attempt to
resolve them when they should not and do not resolve them when you want
them to.
On structured data, we arrived at a distinction between extending the
protocol schema and incorporating lists of tag value pairs.
* Using <any> to extend the protocol is bad, you lose the ability to
perform schema validation on the protocol elements.
* Using <any> for structured tag-value pairs is acceptable and is the
prefered method if you have a tag-value pair that you may need to
instantiate into multiple schemas.
So for example, if X.509 was an XML data format:
* Changes to the X.509v3 cert format should use inheritance/subclassing
so that the cert can be schema validated.
* <any> should be used at the point where X.509v3 requires an
OID-Structure pair defining a certificate extension. This allows an
extension to be incorporated in Certificates, CRLs, OCSP, etc.
> -----Original Message-----
> From: keyprov-bounces@xxxxxxxx
> [mailto:keyprov-bounces@xxxxxxxx] On Behalf Of Hallam-Baker, Phillip
> Sent: Tuesday, March 04, 2008 1:13 PM
> To: Larry Masinter; Hannes.Tschofenig@xxxxxxx;
> hannes.tschofenig@xxxxxxx
> Cc: ietf-xml-use@xxxxxxx; keyprov@xxxxxxxx; xml-dir@xxxxxxxx
> Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question
>
> Sorry for the delay in responding on this, each time I
> started another issue seemed to crop up.
>
> It is easy to get confused about XML extension, it is pretty
> clear to me that there are too many ways to achieve
> extensibility. At various times I have been told that each of
> the schemes is the best, then that I should use a different one.
>
> I don't think that the choice we make matters as much as that
> we make one that can be followed by WGs that follow after
> KEYPROV. I don't think it is essential for KEYPROV to be 100%
> aligned with such proposal, only that we avoid the need to
> return to discuss these issues in future unless it is in
> response to observed problems.
>
>
> There are the following extension options:
>
> Unstructured data:
>
> 1) Qnames
> 2) Reserved numbers
> 3) HTTP based URIs
> 4) URIs that are not normally resolvable
>
> Structured data
>
> 5) Declare an extension point via ANY
> 6) Subclass the schema
> 7) Use Relax
>
>
> Use of Qnames as data is problematic as the semantics of a
> schema prefix are only defined for the XML markup space and
> not for data space. It is no longer possible to renormalize
> the schema prefixes as you would want to do with XML
> Signature and such: AVOID
>
> Use of reserved tags, numbers etc. requires an assigned
> numbers registry. This may be acceptable, possibly preferred
> if the registry already exists. Otherwise the use of URIs is
> prefered as the XML way:
> AVOID unless refering to an existing registry or the
> intention is to block extensions
>
> HTTP URIs are in theory a good plan, the problem is that
> whatever the developers are told, there will always be some
> clueless developer who decides to attempt to fetch the
> referenced resource each time. Recent experience reported by
> W3C suggests that this is a much bigger problem than I thought earlier
>
> URIs in the URN space appear to be the best bet for
> attributes that define unstructured attributes.
>
> Recommendation: define a prefered mechanism for defining IANA
> URNs. This mechanism should allow the WG to assign the code
> points before IANA action at the WG option. If the WG does
> not want early adopters to frontrun an assignment they ask
> IANA to choose a random code point.
>
> These would look something like
> URN:IETF:<xxx>:<wgname:<codepoint> Where xxx is simply the
> series identifier, wgname is the working group name that is
> required to be unique over all time, codepoint is the code point.
>
> This is compatible with OASIS use -
> urn:oasis:names:tc:SAML:1.0:cm:artifact-01 While the IETF is
> not obligated to follow OASIS lead here, it does seem to work
> in that situation and we do not appear to have a clearly
> prefered alternative here. (See http://www.ietf.org/rfc/rfc3121.txt)
>
> A WG could choose completely random attribute tags or encode
> semantics if they really wanted to.
>
> The registration scheme would have to provide for a
> non-authoritative space, or more precisely for a neutral
> space. In many cases, all that is required is to have a tag
> that is not commonly agreed on but not owned by any of the
> participants. It might be appropriate to use the namespace
> urn:iana:rnd:<codepoint> for this.
>
>
> On the structured data issue the problem is rather more
> complex. XML Schema is baroque. I think they were trying too
> hard to make it easy to convert from DTDs to Schema and
> preserve certain aspects. I do not like the lack of
> modularity, it should be possible to combine two schemas that
> have no overlapping element or attribute names to form a
> single composite schema.
>
> But I don't see this problem as being a good enough reason to
> go to Relax-NG which has its own problems. An XML schema
> should be in XML syntax. Regardless, it is not practical to
> insist that the IETF be a Relax-NG only operation and so we
> must have rules for using XML Schema
>
>
> SAML 1.0 used the subclass approach at the insistence of the
> XML experts, the switch to use of ANY in SAML 2.0 appears to
> have been the result of implementation experience.
>
> The problem is that if you use the superclass approach
> without ANY, you can end up having to include a 'glue' schema
> to import values from another schema:
>
> Consider the case where we have an attribute schema 'A' that
> is already defined (e.g. structures that describe various
> user atributes such as their names, addresses, etc.) and we
> wish to make use of this in a base schema 'B'.
>
> In SAML 1.0 it was necessary to write a third schema C
> containing elements that wrap around the members of A that we
> want to use and introduce them into the corresponding
> inheritance classes.
>
>
> The upshot is that despite the processing difficulties, I
> really cannot recommend this approach. It resulted in the
> need to introduce an incompatible SAML upgrade. I understand
> the implementation problems this leads to with current
> generation XML tools (particularly as I use C# and the
> reflection classes) but this is fixable.
>
>
>
> Proposed plan going forward:
>
> 1) Discussion at IETF 71
> We really need to come to a consensus view here, what
> the consensus is matters less than we get some consistency in
> the approach
>
> 2) Architectural ID setting out the consensus approach
>
> 3) ID to specify URI namespace and IANA rules for registering
> names therein.
>
> 4) Regularize KEYPROV and anything else according to the
> proposal but the KEYPROV drafts need not and should not be
> gated on the progress of the architectural proposal since we
> are likely to want to change our minds on that in response to
> KEYPROV implementation experience.
>
>
> -----Original Message-----
> From: keyprov-bounces@xxxxxxxx
> [mailto:keyprov-bounces@xxxxxxxx] On Behalf Of Larry Masinter
> Sent: Thursday, February 21, 2008 9:48 AM
> To: Hannes.Tschofenig@xxxxxxx; hannes.tschofenig@xxxxxxx
> Cc: ietf-xml-use@xxxxxxx; keyprov@xxxxxxxx; xml-dir@xxxxxxxx
> Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question
>
> I prefer using XML namespace qualified names for extensible
> enumerated sets of values, much more than using either
> attributes with string values or content.
>
> So I much prefer <secret> to <Data Name="SECRET"> because
> (presumably) "secret" is one of an enumerated set.
>
> One "test" is that if you take a fragment of the resulting
> XML and translate it (from English, presumably) to another
> language, words in attributes and content would translate,
> but namespace-qualified names would not. (Of course,
> base64-encoded data in element values don't
> count.)
>
> Larry
>
>
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@xxxxxxxx
> http://www.ietf.org/mailman/listinfo/keyprov
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/keyprov
>