See also: IRC log
<trackbot> Date: 12 July 2011
<Dug> http://www.w3.org/2002/ws/ra/chair-tools/attendance.html
<scribe> scribe: Bob
RESOLUTION: minutes of 2011-07-05 accepted
<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access-comments/2011Jul/0001.html
<gpilz> outdated template
<gpilz> they don't like the assertion that there are no security issues
<Yves> http://tools.ietf.org/html/rfc4288
<Yves> http://tools.ietf.org/html/rfc4288#section-10 for the template
<Dug> http://www.w3.org/2002/ws/ra/edcopies/wsevd.html
<Yves> http://www.w3.org/TR/2011/CR-ws-event-descriptions-20110428/#EVD_MIME
http://lists.w3.org/Archives/Public/public-ws-resource-access-comments/2011Jul/0001.html
<Yves> http://www.w3.org/TR/xml/#NT-Name for an xml-id
<Dug> Attributes of type ID are subject to additional normalization rules: removing leading and trailing space characters and replacing sequences of spaces with a single space.
<Yves> "Values of type ID MUST match the Name production. "
<Dug> The Event Type referenced is the Event Type with the @id attribute whos value equals that of the fragment identifier component.
<trutt> http://www.w3.org/TR/xml-id/#processing
<Yves> Name instead of ncname ?
<Yves> http://www.w3.org/TR/SVG/mimereg.html
<gpilz> for every issue . . . spin, spin, spin / there is an excuse . . . spin, spin, spin / and a weasel wording for every problem under heaven
~id must conform to the normalization rules as described in (reference to xml spec)
<Dug> http://www.w3.org/TR/xml-id
<trutt> Note:
<trutt> For interoperability, document producers should use fully normalized values that are legal NCNames in xml:id attributes. from http://www.w3.org/TR/xml-id/#id-avn
<gpilz> The declared type of the attribute, if it has one, is “IDâ€Â. All declarations for xml:id attributes must specify “ID†as the type of the attribute.
<gpilz> <xs:attribute name="id" type="xs:ID"/>
<gpilz> <xs:attribute name='id' type='xs:NCName' use='required'/>
<Dug> The Event Type referenced is the Event Type with the @id attribute whos normalized value equals that of the fragment identifier component.
<Dug> The Event Type referenced is the Event Type with the @id attribute whose normalized value (per [xml:id]) equals that of the fragment identifier component.(
<Yves> +1
<Dug> add ref to xml:id spec too
<Dug> change xml:id to xml-id to make Tom happy :-)
<Dug> change NCName to xs:ID
<Dug> change "non" to "no"
<Yves> use new names form template http://tools.ietf.org/html/rfc4288#section-10
As with other XML types and as noted in [http://www.w3.org/TR/SVG/refs.html#ref-RFC3023] section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail.
Several SVG elements may cause arbitrary URIs to be referenced. In this case, the security issues of [http://www.w3.org/TR/SVG/refs.html#ref-RFC3986], section 7, should be considered.
In common with HTML, SVG documents may reference external media such as images, audio, video, style sheets, and scripting languages. Scripting languages are executable content. In this case, the security considerations in the Media Type registrations for those formats shall apply.
In addition, because of the extensibility features for SVG and of XML in general, it is possible that "image/svg+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of the published specification, this content will be outside the SVG namespace and shall be ignored. Only in the case where the processor recognizes and processes the additional content, or where further pr
<gpilz> Same as that of Section 10 in RFC 3023.
As with other XML types and as noted in [http://www.w3.org/TR/SVG/refs.html#ref-RFC3023] section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail.
<Dug> use gils: + add ref to 3023 in bibl.
<Dug> remove base uri section
<Dug> open an issue
comment on of before end of business on July 13
Yves to forward to ietf if no negative comments on July 14