Re: Protocol Action: 'The Standard Hexdump Format' to Proposed Standard

* The IESG wrote:
>The IESG has approved the following document:
>
>- 'The Standard Hexdump Format '
>   <draft-strombergson-shf-06.txt> as a Proposed Standard

Hmm,

[...]
  Required parameters: charset

  This parameter must exist and must be set to "UTF-8".  No other
  character sets are allowed for transporting SHF data.  The character
  set designator MUST be uppercase.
[...] http://www.ietf.org/internet-drafts/draft-strombergson-shf-06.txt

So we now have

  * no charset parameter (e.g., application/vnd.pwg-xhtml-print+xml)
  * optional charset parameter (e.g., application/xhtml+xml)
  * required charset parameter (e.g., application/shf+xml)

...
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Protocol Action: 'The Standard Hexdump Format' to Proposed Standard

On Thursday, March 24, 2005, 7:39:13 PM, Bjoern wrote:

BH> * The IESG wrote:
>>The IESG has approved the following document:
>>
>>- 'The Standard Hexdump Format '
>>   <draft-strombergson-shf-06.txt> as a Proposed Standard

BH> Hmm,

BH> [...]
BH>   Required parameters: charset

BH>   This parameter must exist and must be set to "UTF-8".  No other
BH>   character sets are allowed for transporting SHF data.  The character
BH>   set designator MUST be uppercase.
BH> [...]
BH> http://www.ietf.org/internet-drafts/draft-strombergson-shf-06.txt

BH> So we now have

BH>   * no charset parameter (e.g., application/vnd.pwg-xhtml-print+xml)
BH>   * optional charset parameter (e.g., application/xhtml+xml)
BH>   * required charset parameter (e.g., application/shf+xml)

Yes, given that this is not a text/* type, if the format allows only a
single encoding, I can't see what purpose the charset parameter serves.

Except, perhaps, to force failure if the content is erroneously sent as

Request for comments regarding draft-mccobb-xplusv-media-type-01

Re: Request for comments regarding draft-mccobb-xplusv-media-type-01

* Gerald McCobb wrote:
>2.1 application/xhtml+voice+xml Usage
>
>   The application/xhtml+voice+xml media type is intended to be a media
>   descriptor for XHTML+Voice documents.
>
>   This media type registration is not intended for email usage.

The draft does not really explain why there is a need for such a
type in the first place; why don't you use application/xhtml+xml?

>      Optional parameters:
>   version:  refers to the XHTML+Voice language version in the document.
>             Acceptable values are 1.0, 1.1, and 1.2 (default).

What are the processing requirements for this parameter?

>   charset:  has the same meaning as the text/html media type.  See
>   section 2 of [RFC 2854].

A word seems to be missing here. It is not really clear why the draft
refers to RFC 2854 rather than RFC 3023 or RFC 3236. 

>      Security considerations:
> 
>   XHTML+Voice is an extension of XHTML and has the same security issues
>   as XHTML.  These include interpreting anchors and forms in HTML
>   documents, and scripting languages and other dynamic interactive
>   capabilities.  See section 7 of [RFC 2854].

So the extensions to XHTML have no security considerations?

>         File extension(s): html, htm, mxml, xvml

I don't think .html and .htm should be listed here, they are already in
common use for application/xhtml+xml and text/html.

>4. Fragment Identifiers
>
>   See section 3 of [RFC 2854].

It is unclear what this means, RFC 2854 and RFC 3236 have inconsistent
rules for fragment identifiers and XHTML+Voice adds new ID attributes
so that the fragment identifier namespaces are different.

>6. Security Considerations
>
>   Security considerations for this media type are discussed in the MIME
>   type registration that appears in section 4.

Section 4 has no security considerations...

>7. References

The draft should be clear about which of these references are
informative and which normative.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

FYI: XML Schema: Component Designators

Hi,

  http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/ is in Last Call,

[...]
  [Definition: A canonical schema component designator is an absolute
  schema component designator that is a URI that has been normalized
  according to the rules given in the update to RFC2396 and where the
  relative schema component designator consists of an xmlns XPointer
  pointer part (if required) followed by a canonicalized xscd XPointer
  pointer part.]

  [Definition: A canonicalized xscd XPointer pointer part is an xscd
  XPointer pointer part where the pointer data is a canonical schema
  component path.]
[...]

As XML Schema schemas are represented "preferably of MIME type
application/xml or text/xml" this might be relevant to the RFC 3023
revision.

regards.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/