RE: [KEYPROV] Tentative Conclusion on XML Design Question

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

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