RE: Proofread of XOP draft

 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: 18 May 2004 19:45
> To: [email protected]
> Subject: Proofread of XOP draft
> 
<SNIP/>
> 
> Most Important
> --------------
> 
> * Section 1. The intro currently says: "When XOP is used as intended,
> binary data will never be encoded in base64 form. Indeed, to 
> add binary
> data into an XML Document, a XOP-aware application will add 
> the linking
> element at the correct location in the XML and place the binary data
> directly into the package. "  That seems too strong, as we do 
> intend that
> the characters be made available in a variety of situations 
> including dsig,
> re-encoding into XML 1.0, etc.  Furthermore, I strongly object to the
> suggestion that applications directly create xop:include 
> elements, as this
> is quite likely to be done by middleware.  How about:  "In a number of
> important XOP applications, binary data need never be encoded 
> in base64
> form. If the data to be included is already available as a 
> binary octet
> stream, then either an application or other software acting 
> on its behalf
> can directly copy that data into a XOP package, at the same 
> time preparing
> suitable linking elements for use in the root part;  when 
> parsing a XOP
> package the binary data can be made available directly to 
> applications, or
> if appropriate, the base64Binary character representation can 
> be computed
> from the binary."

I'm happy with this proposed change.

> 
> * Section 3:  Suggest changing "An informative XML Schema" to "A
> non-normative XML schema".  I hope it's informative either 
> way, but the
> point is that it is not normative.   Any reason not to just say that?

+1

> 
> * Section 3.2: see emails from me and from Gudge suggesting that we
> reference Schema datatypes anyURI for the lexical form of the 
> content of
> the href attribute.  I'm offline and don't have the archive 
> link, but mine
> was sent on Tues 5/18.

Yup, say it's type is xs:anyURI and therefore it's lexical space is that
of xs:anyURI.

> 
> Less Important
> --------------
> 
> * Section 1. The introduction doesn't mention 
> xop-mime:content-type.  This
> seems to be a significant function, since it is for use in 
> user content as
> opposed to just in the xop internals.  Should we not set it up with a
> sentence or two of introduction?  Perhaps something like:  "This
> specification also introduces an attribute 
> xop-mime:content-type which may
> be used in XML documents to indicate the media type of base64Binary
> content.  XOP uses this attribute, if present, to provide 
> suitable typing
> for MIME multipart/related parts."

Sounds fine to me.

> 
> * Section 1.1 Note:  "Mark proposes to change "any W3C 
> recommendation-level
> version of XML" to "XML". The current text comes from the 
> resolution of
> rec20 and rec22. Do we want to change it? "  I'm inclined to 
> keep it as is.
> I'm not sure that "XML" unqualified is sufficiently 
> unambiguous.  I'm not
> arguing that it's actually wrong, but I think we will get 
> questions from
> users asking:  can I use XML 1.1?  Why not provide an answer 
> in advance?
> See also item 1 in the instructions for reconstituting in section 4.2,
> which makes the connection from XML declarations to levels of the XML
> Recommendation.

Not sure I have an opinion here.

> 
> * Section 2:  "The subsection below specifies how a 
> particular packaging
> mechanism, MIME Multipart/Related, is used, but does not 
> preclude the use
> of other packaging mechanisms with the XOP convention."  I 
> suggest adding
> the word normative as follows: "The subsection below specifies
> >normatively< how a particular packaging mechanism, MIME 
> Multipart/Related,
> is used, but does not preclude the use of other packaging 
> mechanisms with
> the XOP convention. "  Reason:  without this, it all seems 
> sort of vague.
> You can do whatever you like.  With this, it makes clear that 
> there is a
> normative multipart representation with conformance 
> requirements specified
> in the rec.  Indeed, you can also use XOP as a framework for 
> inventing your
> own, but the rules for building a multipart are normative 
> when that's what
> you decide to do.

+1

> 
> * Section 5:  "Note that there is currently no convention for 
> structuring
> XOP-based media types." -> "Note that there is currently no 
> convention for
> structuring >the names of< XOP-based media types. "  Reason:  
> this whole
> rec IS about conventions for structuring XOP media types.

+1

> 
> * Section 6:  "The integrity of XOP Packages may need to be 
> ensured. As
> such packages can be transformed to an XML Information Set, 
> existing XML
> Digital Signature techniques can be used to protect such 
> packages. " ->
> "The integrity of >Infosets optimized using XOP< may need to 
> be ensured. As
> XOP  packages can be transformed to recover such Infosets (see section
> 4.2), existing XML Digital Signature techniques can be used 
> to protect such
> them.  

+1 except 'such them.' at the end should just be 'them.'

> Note, however, that a signature over the Infoset does not
> necessarily protect against modifications of other aspects of the XOP
> packaging;  for example, an Infoset signature check might not protect
> against an exchange of position of two non-root parts.  

I'd stop right here. In fact, I might change 'an exchange of position of
two non-root parts' to 're-ordering of non-root parts'

> To 
> protect against
> such modifications, the serialization of the multipart 
> related or other
> package would have to be signed, but no standard means is 
> here proposed for
> computing package-level signatures."  

I would NOT include this text. It's unclear to me what attack is
possible. I understand that two MIME parts might get swapped, 
order wise at the MIME level but at the infoset level they'd still be in
the 'right' order.

> Reason:  should be 
> self-explanatory.
> DSigs over the infoset DO NOT protect the package, and one can imagine
> situations in which protection of the package is needed.  In 
> any case, we
> should be careful in making such claims.
> 
> Editorial or minor
> ------------------
> 
> * Section 1. "In the reverse direction, XOP only allows to 
> extract from an
> XML Infoset base64-encoded data that is in the canonical 
> lexical form. "
> -> "In the reverse direction, XOP is capable of optimizing only
> base64-encoded Infoset data that is in canonical lexical form."

+1

> 
> * Section 3. "Infoset containing such element information 
> item cannot be
> serialized using XOP. "  -> ">Infosets< containing such 
> element information
> >items< cannot be serialized using XOP. "

+1 

> 
> * Section 3.1. "There MAY be zero or more namespace qualified element
> information items in its [children] property. Any such 
> element information
> item MUST have a [namespace name] different of
> "http://www.w3.org/2003/12/xop/include". "  I suggest: "There 
> MAY be zero
> or more namespace qualified element information items in its 
> [children]
> property. Any such element information item MUST have a 
> [namespace name]
> and that name MUST NOT be "http://www.w3.org/2003/12/xop/include". "

+1

> 
> * Section 3.1: Suggest:  "Any other namespace qualified attribute
> information items with a [namespace name] different of
> "http://www.w3.org/2003/12/xop/include". " -> "Other 
> attribute information
> items; these MUST have a [namespace name] the value of which 
> MUST NOT be
> "http://www.w3.org/2003/12/xop/include"."

I think 'Other namespace qualified attribute information items;' as
[namespace name] can be present but have no value ( for unqualified
attributes ). This is also more consistent with your suggested text for
elements above.

> 
> * Section 5: "To enable applications to identify the use of 
> XOP as well as
> the original Infoset's media type, formats wishing to allow XOP
> serialization MUST register a distinct media type that identifies the
> format of the XOP Infoset."  I think it's a bit clumsy to imply that
> formats can wish for things.  How about: "To enable applications to
> identify the use of XOP as well as the original Infoset's 
> media type, a
> distinct media type MUST be registered for each application 
> of XOP to a
> particular XML application vocabulary."

+1 

> 
> * Section 5: "For example, if the format identified by
> "application/soap+xml" wishes to enable applications to identify XOP
> serializations, it MUST register a XOP-specific media type (e.g.,
> "application/soap_xop+xml")."  for the same reason I suggest 
> "For example,
> if the format identified by "application/soap+xml" is to be 
> packaged as XOP
> serializations, then a XOP-specific media type (e.g.,
> "application/soap_xop+xml") MUST be registered. "

+1 

> 
> Notwithstanding the above comments, I think the recent draft 
> is overall
> really good.  Thanks to Herve and Mark, who I believe are 
> responsible for
> most of the hard work on this.

Yup, thanks guys, you've done a great job.

Gudge