Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt

From: Sean Turner <[email-masked]>
Date: Sun, 01 Jan 2012 22:08:42 -0500

Take,

If we're importing schema elements from the schemas listed in 4.1.*, 
then wouldn't the references to those specifications be normative?

spt

On 12/28/11 12:52 AM, Takeshi Takahashi wrote:
> Hello all,
>
> I've just posted the new version of the mile-sci draft.
> Though the text has changed a lot, we basically have only two changes, as
> listed below:
>
> 1. table is changed (see section 4.1)
> 2. IANA description was totally changed
>
> The discussion on EM_XML is still an issue, so I'd appreciate if you could
> kindly share your opinion on that.
> (I personally like the idea Kathleen kindly proposed.)
> The new version tentatively deleted the description of EM_XML, and use the
> xml defined by the IODEF dtype.
>
> Thank you very much for those of you who kindly gave me lots of useful
> comments and supports.
> I wish you a happy new year.
>
> Sincerely,
> Take
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Wednesday, December 28, 2011 2:40 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Managed Incident Lightweight
>> Exchange Working Group of the IETF.
>>
>> 	Title           : IODEF-extension to support structured
>> cybersecurity information
>> 	Author(s)       : Takeshi Takahashi
>>                            Kent Landfield
>>                            Thomas Millar
>>                            Youki Kadobayashi
>> 	Filename        : draft-ietf-mile-sci-01.txt
>> 	Pages           : 34
>> 	Date            : 2011-12-27
>>
>>     This document extends the Incident Object Description Exchange Format
>>     (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched
>>     cybersecurity information exchange among cybersecurity entities by
>>     embedding structured information formatted by specifications,
>>     including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R)
>>     [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL
>>     [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF].
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-sci-01.txt
>>
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: <[email-masked]>
Date: Mon, 2 Jan 2012 14:31:10 -0500

Greetings,

> xml defined by the IODEF dtype.

I also like Kathleen's suggested approach of using the IODEF dtype instead of EM_XML, especially as that approach is also being used to include IODEF content in RID (see the ReportSchema class in draft-ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems like a good idea for consistency.

I think some more discussion would be useful (and would like to see the opinions of others), as I see some differences between how this is being done in the rfc6045-bis draft vs. the sci draft:
	
(1) Schema identification

RID identifies the included XML schema by XML namespace and version.  The XML namespace is in the XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, and the schema version is in the Version or ext-Version attribute of that class.  IODEF 1.0 is the default if these attributes are omitted.

SCI extension classes (e.g., AttackPattern) use an additional required SpecificationID attribute (a short ENUM xsd:string) that includes both an acronym and the version of the specification - the XML namespace is left to be declared by the included XML.

(2) Version of schema vs. specification

For RID, the Version or Version-ext attribute of the ReportSchema class contains the XML schema version for the included XML.

For SCI, the version that's part of the SpecificationID attribute of the extension classes is the version of the specification for the included XML.  This specification version may not match the version of the XML schema defined by that specification.

(3) Version - same attribute name used for two different purposes.

For RID, the Version attribute of the ReportSchema class is the schema version for the included XML for standard schemas (ext-Version is used for non-standard schemas).

For SCI, the Version attribute of the extension classes is the version of the IODEF-SCI schema.

My 0.02 (which isn't worth much more than that) is that SpecificationID seems to be useful as a convenient human-readable string to identify the type of XML content (for RID, that could default to IODEF if omitted), and I don't have a strong preference for the two version topics as long as a single approach is adopted.

Could others on the list speak up to provide opinions on how to handle these topics?

Thanks,
--David

> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Wednesday, December 28, 2011 12:52 AM
> To: [email-masked]
> Cc: Brian Trammell; Moriarty, Kathleen; Black, David; [email-masked]
> Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt
> 
> Hello all,
>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 3 Jan 2012 22:04:54 +0900

Hello Sean,

Thank you for pointing it out. I appreciate that.
I should move these references to normative section.

Thank you.
Take

> From: Sean Turner [mailto:[email-masked]]
> Sent: Monday, January 02, 2012 12:09 PM
> To: Takeshi Takahashi
> Cc: [email-masked]
> Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt
> 
> Take,
> 
> If we're importing schema elements from the schemas listed in 4.1.*, then
> wouldn't the references to those specifications be normative?
> 
> spt
> 
> > Though the text has changed a lot, we basically have only two changes,
> > as listed below:
> >
> > The discussion on EM_XML is still an issue, so I'd appreciate if you
> > could kindly share your opinion on that.
> > (I personally like the idea Kathleen kindly proposed.) The new version
> > tentatively deleted the description of EM_XML, and use the xml defined
> > by the IODEF dtype.
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of [email-masked]
> >> directories. This draft is a work item of the Managed Incident
> >> Lightweight Exchange Working Group of the IETF.
> >>

---

From: <[email-masked]>
Date: Tue, 3 Jan 2012 09:52:17 -0500

Take and the other authors of he SCI draft are reviewing this issue.  Feedback on how RID encapsulates a document would be helpful.  The approach used in RID is consistent with IODEF.  

I would like to clarify one of the assumptions from below to avoid confusion.

1) The version can be left out for IODEF when included in a RID document as it is listed in the namespace definition, not because it is the default schema.  In case other schemas also include the version in the namespace declaration, this was left as optional.

3) Are you advocating for a specificationID to be included in addition to the namespace declaration?  

Thanks,
Kathleen (editor)
________________________________________
From: Black, David
Sent: Monday, January 02, 2012 2:31 PM
To: Takeshi Takahashi; [email-masked]
Cc: Moriarty, Kathleen
Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt

Greetings,

Thanks,
--David

---

From: <[email-masked]>
Date: Tue, 3 Jan 2012 12:47:52 -0500

Hi Kathleen,

> 3) Are you advocating for a specificationID to be included in addition to the namespace declaration?

Not exactly ;-).

I'm not "advocating" for inclusion of specificationID - rather I'd like to see RID and SCI be consistent in their use of SpecificationID and Version.  For SpecificationID, that could be accomplished by adding it to RID or taking it out of SCI; both approaches seem reasonable to me.

What do other people think ought to be done here and why?

Thanks,
--David

> From: Moriarty, Kathleen
> Sent: Tuesday, January 03, 2012 9:52 AM
> To: Black, David; Takeshi Takahashi; [email-masked]
> Take and the other authors of the SCI draft are reviewing this issue.  Feedback on how RID encapsulates
> a document would be helpful.  The approach used in RID is consistent with IODEF.
> 
> 1) The version can be left out for IODEF when included in a RID document as it is listed in the
> namespace definition, not because it is the default schema.  In case other schemas also include the
> version in the namespace declaration, this was left as optional.
> 
> I also like Kathleen's suggested approach of using the IODEF dtype instead of EM_XML, especially as
> that approach is also being used to include IODEF content in RID (see the ReportSchema class in draft-
> ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems like a good idea for
> consistency.
> 
> I think some more discussion would be useful (and would like to see the opinions of others), as I see
> some differences between how this is being done in the rfc6045-bis draft vs. the sci draft:
> 
> RID identifies the included XML schema by XML namespace and version.  The XML namespace is in the
> XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, and the schema version is in the
> Version or ext-Version attribute of that class.  IODEF 1.0 is the default if these attributes are
> omitted.
> 
> SCI extension classes (e.g., AttackPattern) use an additional required SpecificationID attribute (a
> short ENUM xsd:string) that includes both an acronym and the version of the specification - the XML
> namespace is left to be declared by the included XML.
> 
> For SCI, the version that's part of the SpecificationID attribute of the extension classes is the
> version of the specification for the included XML.  This specification version may not match the
> version of the XML schema defined by that specification.
> 
> For RID, the Version attribute of the ReportSchema class is the schema version for the included XML
> for standard schemas (ext-Version is used for non-standard schemas).
> 
> My 0.02 (which isn't worth much more than that) is that SpecificationID seems to be useful as a
> convenient human-readable string to identify the type of XML content (for RID, that could default to
> IODEF if omitted), and I don't have a strong preference for the two version topics as long as a single
> approach is adopted.
>

---

From: "Panos Kampanakis" <[email-masked]>
Date: Mon, 16 Jan 2012 23:32:47 -0500

I agree David. 

It seems the RID's XMLSchemaID  and SCI's SpecificationID are equivalent and
depict the included schema identifier. But for RID the XMLSchemaID is the
namespace of the included schema (default IODEF), and in SCI the
SpecificationID is the "notional" string ID for various schemata. For the
Version, RID is IODEF version but in SCI it is the IODEF-SCI version. 2
inconsistencies that would be better if they matched in Rid and SCI.

IMO, changing SCI's SpecificationID to be the IANA supported namespace for
XDDF, CCE, CAPEC etc and making the Version to be the IODEF version (as in
RID) would be sufficient. I am not sure why the IODEF-SCI version needs to
be in the extension classes since it is included in the iodef-sci namespace
definition earlier anyway.

Rgs,
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 03, 2012 12:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt

Hi Kathleen,

Not exactly ;-).

I'm not "advocating" for inclusion of specificationID - rather I'd like to
see RID and SCI be consistent in their use of SpecificationID and Version.
For SpecificationID, that could be accomplished by adding it to RID or
taking it out of SCI; both approaches seem reasonable to me.

Thanks,
--David

> 3) Are you advocating for a specificationID to be included in addition to
the namespace declaration?
could
> For RID, the Version or Version-ext attribute of the ReportSchema class
contains the XML schema
> version for the included XML.
> 
as
> > The discussion on EM_XML is still an issue, so I'd appreciate if you
could
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> > > directories. This draft is a work item of the Managed Incident
Lightweight

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 17 Jan 2012 14:14:25 +0900

Hi Panos,

Thank you for the kind comments.
I agree to change the draft to avoid any inconsistency between the drafts.

> IMO, changing SCI's SpecificationID to be the IANA supported namespace
> for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version

In this case, we do not need the "notional" string ID defined in the IANA
table.
Currently, each entry of the table has (ID, specification name, version,
namespace, specification url, applicable classes).
So, I would delete the "ID" and change the entry into (namespace,
specification name, version, specification url, applicable classes)

Also, for the rest of the comments, I like your proposal, and let me change
the draft.

I appreciate your assistance.
Thank you.

Take

> Panos Kampanakis
> Sent: Tuesday, January 17, 2012 1:33 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> It seems the RID's XMLSchemaID  and SCI's SpecificationID are equivalent
> and depict the included schema identifier. But for RID the XMLSchemaID
> is the namespace of the included schema (default IODEF), and in SCI the
> SpecificationID is the "notional" string ID for various schemata. For
> the Version, RID is IODEF version but in SCI it is the IODEF-SCI version.
> 2 inconsistencies that would be better if they matched in Rid and SCI.
> 
> IMO, changing SCI's SpecificationID to be the IANA supported namespace
> for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version
> (as in
> RID) would be sufficient. I am not sure why the IODEF-SCI version needs
> to be in the extension classes since it is included in the iodef-sci
> namespace definition earlier anyway.
> 
> Rgs,
> Panos
> 
> 
> > 3) Are you advocating for a specificationID to be included in addition
> > to
> I'm not "advocating" for inclusion of specificationID - rather I'd like
> to see RID and SCI be consistent in their use of SpecificationID and
> Version.
> > a document would be helpful.  The approach used in RID is consistent
> > with
> IODEF.
> >
> > 1) The version can be left out for IODEF when included in a RID
> > document
> as it is listed in the
> > namespace definition, not because it is the default schema.  In case
> > other
> schemas also include the
> > 3) Are you advocating for a specificationID to be included in addition
> > to
> > > (I personally like the idea Kathleen kindly proposed.) The new
> > > version tentatively deleted the description of EM_XML, and use
> the
> > I also like Kathleen's suggested approach of using the IODEF dtype
> > instead
> of EM_XML, especially as
> > that approach is also being used to include IODEF content in RID (see
> > the
> ReportSchema class in draft-
> > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems
> > like
> a good idea for
> > consistency.
> >
> > I think some more discussion would be useful (and would like to see
> > the
> opinions of others), as I see
> > some differences between how this is being done in the rfc6045-bis
> > draft
> vs. the sci draft:
> >
> > RID identifies the included XML schema by XML namespace and version.
> > The
> XML namespace is in the
> > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class,
> > and
> the schema version is in the
> > Version or ext-Version attribute of that class.  IODEF 1.0 is the
> > default
> if these attributes are
> > omitted.
> >
> > short ENUM xsd:string) that includes both an acronym and the version
> > of
> the specification - the XML
> > For SCI, the version that's part of the SpecificationID attribute of
> > the
> extension classes is the
> > For SCI, the Version attribute of the extension classes is the version
> > of
> the IODEF-SCI schema.
> >
> > My 0.02 (which isn't worth much more than that) is that
> > SpecificationID
> seems to be useful as a
> > convenient human-readable string to identify the type of XML content
> > (for
> RID, that could default to
> > > 1. table is changed (see section 4.1) 2. IANA description was
> > > totally changed
> > >
> > > (I personally like the idea Kathleen kindly proposed.) The new
> > > version tentatively deleted the description of EM_XML, and use
> the
> > > Thank you very much for those of you who kindly gave me lots of
> > > useful comments and supports.
> > > >    [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM]
> > > > [CWSS],
> OCIL

---

From: "Panos Kampanakis" <[email-masked]>
Date: Tue, 17 Jan 2012 09:38:24 -0500

Looks good to me Take.
So after this change takes place, the Specification or XMLSchema or
SpecificationID ENUM type of the extension classes (AttackPattern,
Vulnerability etc) will include the namespace of each specification right?

Panos

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Tuesday, January 17, 2012 12:14 AM
To: 'Panos Kampanakis'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt

Hi Panos,

Take

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 18 Jan 2012 01:45:12 +0900

Hi Panos, thank you for your confirmation.

Yes, each class has a field containing the namespace.
SpecificationID field will be used for describing the namespace, instead of
the notional IDs.

As an example, let me put the text of the AttackPattern class after the
modification.
The description of the SpecificationID was changed, and the version
attribute was deleted(, and we do not have the notional string ID).

----------------------------------------------------------------------------
--
4.3.1.  AttackPattern

   An AttackPattern consists of an extension to the
   Incident.Method.AdditionalData element with a dtype of "xml".  The
   extension describes attack patterns of incidents or events.

   It is recommended that Method class SHOULD contain one or more of the
   extension elements whenever available.

   An AttackPattern class is structured as follows.

   +------------------------+
   | AttackPattern          |
   +------------------------+
   | ENUM SpecificationID   |<>--(0..*)-[ RawData ]
   | STRING AttackPatternID |<>--(0..*)-[ Reference ]
   |                        |<>--(0..*)-[ PlatformID ]
   +------------------------+

                       Figure 2: AttackPattern class

   This class has the following attributes.

   SpecificationID:  REQUIRED.  ENUM.  The namespace of the
      specification and its version that the RawData element follows.
      The value should be chosen from the namespaces listed in
      Section 4.1, which could be developed further by IANA.  In case a
      RawData or Reference element is provided along with this
      attribute, writers/senders MUST ensure that this namespace is
      consistent with the one provided by the element; if a reader/
      receiver detects an inconsistency, it SHOULD prefer the value of
      this attribute, and SHOULD log the inconsistency so a human can
      correct the problem.

   AttackPatternID:  OPTIONAL.  STRING.  An ID of an attack pattern to
      be reported.  This attribute SHOULD be used whenever such ID is
      available, but could be omitted if no such ID is available.  In
      this case, either RawData or Reference elements, or both of them,
      MUST be provided.  In case a RawData or Reference element is
      provided along with this attribute, writers/senders MUST ensure
      that this ID is consistent with the one provided by the element;
      if a reader/receiver detects an inconsistency, it SHOULD prefer
      the value of this attribute, and SHOULD log the inconsistency so a
      human can correct the problem.

   The AttackPattern class is composed of the following aggregate
   classes.

   RawData:  Zero or more.  XMLDATA.  A complete document that is
      formatted according to the specification and its version
      identified by the value of the SpecificationID with the
      Section 4.1.

   Reference:  Zero or more of iodef:Reference [RFC5070].  This element
      allows an IODEF document to include a link to a structured
      information instead of directly embedding it into a RawData
      element.

   PlatformID:  Zero or more.  An identifier of software platform
      involved in the specific attack pattern, which is elaborated in
      Section 4.3.2.  Some of the structured information embedded in the
      RawData element may include the identifier within it.  In this
      case, this PlatformID element SHOULD NOT be used.  If a reader/
      receiver detects the identifiers in both RawData and PlatformID
      elements and their inconsistency, it SHOULD prefer the identifiers
      derived from the PlatformID element, and SHOULD log the
      inconsistency so a human can correct the problem.
----------------------------------------------------------------------------
--

Let me change the other parts including schema for the next version of the
draft.

Thank you.
Take

> From: Panos Kampanakis [mailto:[email-masked]]
> Sent: Tuesday, January 17, 2012 11:38 PM
> To: 'Takeshi Takahashi'; [email-masked];
> [email-masked]
> Cc: [email-masked]
> > Of Panos Kampanakis
> > It seems the RID's XMLSchemaID  and SCI's SpecificationID are
> > equivalent and depict the included schema identifier. But for RID the
> > XMLSchemaID is the namespace of the included schema (default IODEF),
> > and in SCI the SpecificationID is the "notional" string ID for various
> > schemata. For the Version, RID is IODEF version but in SCI it is the
> IODEF-SCI version.
> > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF
> > version (as in
> > RID) would be sufficient. I am not sure why the IODEF-SCI version
> > needs to be in the extension classes since it is included in the
> > iodef-sci namespace definition earlier anyway.
> >
> > Rgs,
> > Panos
> >
> >
> > Of [email-masked]
> > > 3) Are you advocating for a specificationID to be included in
> > > addition to
> > I'm not "advocating" for inclusion of specificationID - rather I'd
> > like to see RID and SCI be consistent in their use of SpecificationID
> > and Version.
> > > 3) Are you advocating for a specificationID to be included in
> > > addition to
> > > that approach is also being used to include IODEF content in RID
> > > (see the
> > > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice
> > > seems like
> > a good idea for
> > > consistency.
> > >
> > > SCI extension classes (e.g., AttackPattern) use an additional
> > > required
> > SpecificationID attribute (a
> > > version of the specification for the included XML.  This
> > > specification
> > version may not match the
> > > For RID, the Version attribute of the ReportSchema class is the
> > > schema
> > version for the included XML
> > > For SCI, the Version attribute of the extension classes is the
> > > version of
> > the IODEF-SCI schema.
> > >
> > > Could others on the list speak up to provide opinions on how to
> > > handle
> > these topics?
> > >
> > > Thanks,
> > > --David
> > >
> > > > > A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts directories. This draft is a work item of the
> > > > > Managed Incident
> > Lightweight
> > > > >    This document extends the Incident Object Description
> > > > > Exchange
> > Format
> > > > >    cybersecurity information exchange among cybersecurity
> > > > > entities
> > by

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 11:51:37 -0500

Hi Take,

The closer you can match it to RID, the better as it may ease the task for IANA and help integrators.

Thank you!
Kathleen (as author)

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Tuesday, January 17, 2012 11:45 AM
To: 'Panos Kampanakis'; Black, David; Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt

Thank you.
Take

> > version

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 18 Jan 2012 02:07:51 +0900

Hi Kathleen,

Thank you for the comment.
Yes I agree. 

I guess you are talking about the attribute name and its explanation,
especially the "XMLSchemaID" attribute (in RID draft).
I also thought I could use the same attribute name, but I am rather hesitant
to use the name "XMLSchemaID" in the SCI draft since I would like to
identify namespace (instead of directly identifying the schema), at this
moment.

In any case, I basically agree to minimize the differences between the two
drafts.
So, let me still modify sentences before submitting the next version.

Thank you.
Take

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 18, 2012 1:52 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> SpecificationID field will be used for describing the namespace, instead
> of the notional IDs.
> 
> Let me change the other parts including schema for the next version of
> the draft.
> 
> Thank you.
> Take
> 
> 
> 
> > > IMO, changing SCI's SpecificationID to be the IANA supported
> > > namespace for XDDF, CCE, CAPEC etc and making the Version to be the
> > > IODEF version
> >
> > In this case, we do not need the "notional" string ID defined in the
> > IANA table.
> > Currently, each entry of the table has (ID, specification name,
> > version, namespace, specification url, applicable classes).
> > > equivalent and depict the included schema identifier. But for RID
> > > the XMLSchemaID is the namespace of the included schema (default
> > > IODEF), and in SCI the SpecificationID is the "notional" string ID
> > > for various schemata. For the Version, RID is IODEF version but in
> > > SCI it is the
> > IODEF-SCI version.
> > > IMO, changing SCI's SpecificationID to be the IANA supported
> > > namespace for XDDF, CCE, CAPEC etc and making the Version to be the
> > > IODEF version (as in
> > > like to see RID and SCI be consistent in their use of
> > > SpecificationID and Version.
> > > > Take and the other authors of the SCI draft are reviewing this
issue.
> > > Feedback on how RID encapsulates
> > > > a document would be helpful.  The approach used in RID is
> > > > consistent with
> > > IODEF.
> > > >
> > > > namespace definition, not because it is the default schema.  In
> > > > case other
> > > schemas also include the
> > > > > The discussion on EM_XML is still an issue, so I'd appreciate
> if
> > > > > you
> > > could
> > > > I think some more discussion would be useful (and would like to
> > > > see the
> > > > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema
> > > > class, and
> > > > short ENUM xsd:string) that includes both an acronym and the
> > > > version of
> > > > convenient human-readable string to identify the type of XML
> > > > content (for
> > > > IODEF if omitted), and I don't have a strong preference for the
> > > > two
> > > version topics as long as a single
> > > > approach is adopted.
> > > >
> > > > > The discussion on EM_XML is still an issue, so I'd appreciate
> if
> > > > > you
> > > could