Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Mar 2008 10:12:38 -0800

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Larry Masinter
Sent: Thursday, February 21, 2008 9:48 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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
[email-masked]
http://www.ietf.org/mailman/listinfo/keyprov
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Mar 2008 06:26:17 -0800

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.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
> Sent: Tuesday, March 04, 2008 1:13 PM
> To: Larry Masinter; [email-masked]; 
> [email-masked]
> 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.
> 
> 
> 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.
> 
> 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 
> 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.
> 
> 
> 
>      We really need to come to a consensus view here, what 
> the consensus is matters less than we get some consistency in 
> the 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.
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Larry Masinter
> 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
> 
>