Thank you for your message.
The iana(a)iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures. In order to process
your message we need to confirm that it came from a real email address.
To confirm your message, you can either:
1) Reply to this message, without altering the subject line
The "Re: " added by many mail clients is OK, but please note
that this method is *not* foolproof.
or
2) Visit the URL
<http://confirm.icann.org/?s=71f18dfe1e15cc09&l=iana@icann.org>
If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.
For your reference, the subject of the message you sent was:
"{Filename?} Re: Thanks :)"
and it arrived at IANA approximately at Wed Nov 3 17:23:44 2004.
---------------------------------------------------------------
ConfirmSystem: iana(a)icann.org [[71f18dfe1e15cc09]]
1
Dear Scalable Vector Graphics Working Group,
http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
register the "image/svg+xml" MIME Type but the registration lacks the
charset parameter as defined in RFC 3023. This defeats the purpose of
the +xml convention which attempts to provide a means for generic XML
processing.
Generic XML tools such as Validators, Editors, XSLT and XQuery
processors, and full-text XML search engines would need to maintain
special knowledge to ignore the charset parameter for image/svg+xml
documents which is expensive and unlikely to happen. In fact, a number
of deployed tools already don't do that, for example the W3C Markup
Validator would need to be updated with special code for image/svg+xml
in order to comply with the registration.
Thus, please change the registration to be consistent with application/
xml as defined in RFC 3023.
regards.
Please review the MIME type registration template described below. The IESG
has received a request to register this MIME type in the standards tree. It
is a product of Ecma International. A URL for the formal specification is
included in the template.
-Scott-
----------
MIME media type name: application
MIME subtype name: csta+xml
Required parameters: (none)
Optional parameters: (none)
Encoding considerations:
This content type uses XML, employing UTF-8 character encoding.
Security considerations:
This content type is designed to carry information about users involved with
communications which may be considered private information. For example, the
identity of a calling party in a voice call. This content type is also
designed to be used to control communication calls and communication devices
such as telephones.
Appropriate precautions should be taken to insure that applications
observing and controlling communications and communication devices using
CSTA are authorized to do so.
Interoperability considerations:
application/csta+xml documents are specified by the XML schemas standardized
in ECMA-323.
Published specification:
The published Standard ECMA-323 is available at:
http://www.ecma-international.org/publications/standards/Ecma-323.htm
Applications which use this media type:
The application/csta+xml MIME type can be used to identify CSTA XML
(ECMA-323) instance documents.
Additional information:
CSTA XML (ECMA-323) is an application level protocol that enables an
application to control and observe communications involving various types of
media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
and devices associated with the media.
Person & email address to contact for further information:
Ecma Secretariat
Rue du Rhone114
CH-1204 Geneva
Switzerland
secretariat(a)ecma-international.org
Intended usage: common
Author/change controller:
The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
Working Group.
On Monday, November 1, 2004, 9:46:15 PM, Boris wrote:
BZ> Chris Lilley wrote:
>> On the contrary! The +xml convention clearly indicates, for an unknown
>> media type, that it is xml; thus, that an XML processor should be used;
>> which will correctly determine the encoding from the xml encoding
>> declaration or lack therof.
BZ> I think the concern was about what happens when someone sends the
BZ> following HTTP header:
BZ> Content-Type: image/svg+xml; charset=iso-8859-1
BZ> combined with an XML document that has no encoding declaration (so
BZ> defaulting to UTF-8).
That is (for a random +xml media type) currently allowed. It is, as you
say, a problem. (It defaults to UTF-8 or UTF-16 depending on the
presence of absence of a BOM and, if present, what bytes represent it).
BZ> Now per the type registration for "image/svg+xml", the above
BZ> Content-Type header is invalid, right?
Yes. Instead of an optional parameter which should not be used and if
used, causes problems, the proposal is to not have the parameter.
BZ> So what's a UA to do? What encoding to use?
Under which rules? Currently, that is a malformed document that has been
temporarily made well formed while in transit. If saved, it needs to be
rewritten (some implementations do this, most do not). Note that if the
document used DSig, that would actually break it.
BZ> Using UTF-8 means hardcoding knowledge about the fact
BZ> that image/svg+xml, unlike most other character-based types used today,
BZ> doesn't have a charset parameter.
No, it doesn't. This is not specific to SVG, it could (and should) be
adopted by any non-text +xml registration.
>> No, they would not. RFC 3023 already allows the charset to be omitted,
>> and gives rules to follow for this case. SVG follows those rules, as the
>> registration document makes plain.
BZ> The problems arise when there IS a charset parameter.
Exactly. The code path for when there isn't one is well implemented and
interoperable, today.
BZ> I don't think
BZ> anyone ever claimed there is a problem when the charset parameter is
BZ> omitted.
Correct. There is no problem when its omitted, for SVG or for anything
else.
>> In general, a representation provider SHOULD NOT specify the
>> character encoding for XML data in protocol headers since the data is
>> self-describing
BZ> Given that this is a not a MUST NOT,
Its a should not, because for text/* you have to unless your data is
guaranteed to always be US-ASCII (and even then, it is required to fall
back to text/plain; charset=us-ascii) and because it was not desired to
force a change on legacy formats, just to stop the problem spreading to
new formats.
BZ> people will continue to do this in
BZ> some cases (particularly as some web servers automatically tack on a
BZ> "charset" parameter to Content-Type headers).
Which leads us to
Server software designers SHOULD NOT specify a default Internet media
type in the default configuration shipped with the server.
http://www.w3.org/2001/tag/doc/mime-respect.html#self-describing
Some web servers do that, agreed. Including the W3C one. Its wrong, and
it causes pain.
Some of that is because of the requirements of the text/* media type
tree. For XML, that is being dealt with in the RFC 3023 revision by
deprecating text/xml.
--
Chris Lilley mailto:chris@w3.org
Chair, W3C SVG Working Group
Member, W3C Technical Architecture Group
Thank you for your message.
The iana(a)iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures. In order to process
your message we need to confirm that it came from a real email address.
To confirm your message, you can either:
1) Reply to this message, without altering the subject line
The "Re: " added by many mail clients is OK, but please note
that this method is *not* foolproof.
or
2) Visit the URL
<http://confirm.icann.org/?s=ca7128ef62ae0fe9&l=iana@icann.org>
If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.
For your reference, the subject of the message you sent was:
"{Filename?} Re:"
and it arrived at IANA approximately at Sun Oct 31 19:56:37 2004.
---------------------------------------------------------------
ConfirmSystem: iana(a)icann.org [[ca7128ef62ae0fe9]]
1
Thank you for your message.
The iana(a)iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures. In order to process
your message we need to confirm that it came from a real email address.
To confirm your message, you can either:
1) Reply to this message, without altering the subject line
The "Re: " added by many mail clients is OK, but please note
that this method is *not* foolproof.
or
2) Visit the URL
<http://confirm.icann.org/?s=b8cff28327f85e7c&l=iana@icann.org>
If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.
For your reference, the subject of the message you sent was:
"{Filename?} Re: Thank you!"
and it arrived at IANA approximately at Fri Oct 29 04:03:54 2004.
---------------------------------------------------------------
ConfirmSystem: iana(a)icann.org [[b8cff28327f85e7c]]
4
Thank you for your message.
The iana(a)iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures. In order to process
your message we need to confirm that it came from a real email address.
To confirm your message, you can either:
1) Reply to this message, without altering the subject line
The "Re: " added by many mail clients is OK, but please note
that this method is *not* foolproof.
or
2) Visit the URL
<http://confirm.icann.org/?s=c1bcd9ea4cb39927&l=iana@icann.org>
If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.
For your reference, the subject of the message you sent was:
"{Filename?} Re: Hello"
and it arrived at IANA approximately at Fri Oct 29 03:37:41 2004.
---------------------------------------------------------------
ConfirmSystem: iana(a)icann.org [[c1bcd9ea4cb39927]]
3
Thank you for your message.
The iana(a)iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures. In order to process
your message we need to confirm that it came from a real email address.
To confirm your message, you can either:
1) Reply to this message, without altering the subject line
The "Re: " added by many mail clients is OK, but please note
that this method is *not* foolproof.
or
2) Visit the URL
<http://confirm.icann.org/?s=83f3d701c0925134&l=iana@icann.org>
If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.
For your reference, the subject of the message you sent was:
"{Filename?} Re: Thanks :)"
and it arrived at IANA approximately at Fri Oct 29 03:27:40 2004.
---------------------------------------------------------------
ConfirmSystem: iana(a)icann.org [[83f3d701c0925134]]
2
Thank you for your message.
The iana(a)iana.org address collects a tremendous amount of spam, and we
have been forced to implement protective measures. In order to process
your message we need to confirm that it came from a real email address.
To confirm your message, you can either:
1) Reply to this message, without altering the subject line
The "Re: " added by many mail clients is OK, but please note
that this method is *not* foolproof.
or
2) Visit the URL
<http://confirm.icann.org/?s=f27213adb9130923&l=iana@icann.org>
If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.
For your reference, the subject of the message you sent was:
"{Filename?} Re: Hi"
and it arrived at IANA approximately at Fri Oct 29 01:05:37 2004.
---------------------------------------------------------------
ConfirmSystem: iana(a)icann.org [[f27213adb9130923]]
1
Hi,
I would like to have a pre registration request review of the below
propsed MIME type for a RTP payload format. This registration request is
intended to use the updated registration procedure based on
specification available from other standards body.
The specification that the registration belongs to can be found in the
following 3GPP contribution:
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip
Which is the specification delta that included the RTP payload format
defined within to the following specification:
http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip
The registration template for this looks like the following:
------------------------------------------------------------
MIME media type name: audio, video, text, application, image
MIME subtype name: rtp.enc.aescm128
Required parameters:
opt: The payload type number of the payload type contained in the
encrypted payload. An integer value between 0-127.
rate: The timestamp rate of this payload type, which shall be the same
as that of the original payload type. This is an integer value
between 1 and 2^32.
ContentID: The OMA DRM content ID [75] used to identify the content when
establishing a crypto context. The value is an RFC 2396 [60]
URI, which shall be quoted using <">.
RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The
value is an URI in accordance with RFC 2396 [60], which shall be
quoted using <">.
IVnonce: The value of this parameter is the nonce that forms the IV as
specified by the crypto transform, encoded using Base 64 [69].
Optional parameters:
SelectiveEncryption: Indicates if this stream is selectively
encrypted. Allowed values are 0 (false) and 1 (true). If not
present, selective encryption shall not be used. Please note
that unless this indicator is integrity protected, it fulfils no
purpose.
Encoding considerations:
This type is only defined for transfer via RTP (RFC 3550).
Security considerations:
See considerations raised in RTP RFC 3550 [9] and any applicable
profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS
26.234, Release 6, Annex K for comments on security issues. The main
issues that exists are:
- This RTP payload format only confidentiality protects the RTP payload,
thus header information is leaked, similarly to SRTP.
- The use of stream ciphers as AES CM and no integrity protection allows
an attacker to purposefully attack the content of the encrypted RTP
payload by switching individual bits.
- The usage of selective encryption without integrity protection allows
for an attacker to perform any replacements of complete RTP payloads and
packets it desires.
- The payload format makes the receiver vulnerable to denial of service
attacks that inserts RTP packets into the stream, that the receiver then
interprets as being encrypted thus wasting computational resources. To
prevent this attack, authentication needs to be used.
Interoperability considerations:
Published specification:
3GPP TS 26.234, Release 6.
Open Mobile Alliance DRM Content Format V2.0
Applications which use this media type:
Third Generation Partnership Project (3GPP) Packet-switched
Streaming Service (PSS) clients and servers, which supports the
Open Mobile Alliance's specification of Digital Rights
Management version 2.0.
Additional information:
Magic number(s): N/A
File extension(s): N/A
Macintosh File Type Code(s): N/A
Person & email address to contact for further information:
magnus.westerlund(a)ericsson.com
Intended usage:
Common
Author/Change controller:
3GPP TSG SA
---- End of template ---
Hope for comments within a week. Otherwise any changes within 3GPP will
be more difficult.
Thanks
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com
