Subject: [ietf-types] Registration of media type application/vcard+xml

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Apr 2011 13:26:08 -0400

Type name:  application

   Subtype name:  vcard+xml

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  Same as for application/xml.

   Security considerations:  See Section 7 of [draft-ietf-vcarddav-
      vcardrev-08].

   Interoperability considerations:  This media type provides an
      alternative syntax to vCard data [draft-ietf-vcarddav-vcardrev-08]
      based on XML.

   Published specification:  [draft-ietf-vcarddav-vcardrev-08]

   Applications which use this media type:  Applications that currently
      make use of the text/vcard media type can use this as an
      alternative.

   Additional information:

      Magic number(s):  none

      File extension(s):  .xvc

      Macintosh file type code(s):  none

   Person & email address to contact for further information:  Simon
      Perreault <[email-masked]>

   Intended usage:  COMMON

   Restrictions on usage:  none

   Author:  Simon Perreault

   Change controller:  IETF

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 07 Apr 2011 22:12:00 +0200

>   Optional parameters:  none

If you do not specify an optional 'charset' parameter, it is ambiguous
what the encoding of `application/vcard+xml;charset=...` is; if you only
read the registration you are likely to ignore the parameter, while, if
you read RFC 3023 you expect the 'charset' parameter to specify the en-
coding, which has interoperability and security implications.

If this omission of the parameter is not an oversight, I would expect a
rationale for its omission as part of the review request and expect the
interoperability and security issues that arise from this to be noted in
the specification.

>   Encoding considerations:  Same as for application/xml.

This should use the wording given in RFC 3023 section 7.1.

>   Security considerations:  See Section 7 of [draft-ietf-vcarddav-

This reference appears to be outdated. In -18 I don't see a reference to
RFC 3023 which is RECOMMENDED in RFC 3023.

>   Published specification:  [draft-ietf-vcarddav-vcardrev-08]

This should probably be [RFCXXXX] if the idea is to advance the document
to RFC status but I would expect the RFC editor to take care of that.

>      make use of the text/vcard media type can use this as an

I think this should identify the kind of application in addition to the
indirect reference, something like "applications that maintain or pro-
cess contact information" or something like that.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Paul Libbrecht <[email-masked]>
Date: Thu, 7 Apr 2011 22:14:59 +0200

Simon,

may I suggest to add clipboard flavor names?
It would be useful I feel to allow applications to rely on predefined clipboard names.

See OpenXPS, SVG, or MathML recent registrations that you could follow for the how-to.

paul

Le 7 avr. 2011 à 19:26, Simon Perreault a écrit :

> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Apr 2011 16:27:07 -0400

> coding, which has interoperability and security implications.

I will update this to read:

   Optional parameters: charset as defined for application/xml in
      [RFC3023]; per [RFC3023], use of the charset parameter with the
      value "utf-8" is "STRONGLY RECOMMENDED"

> This should use the wording given in RFC 3023 section 7.1.

I will update this to read:

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in [RFC3023]

> RFC 3023 which is RECOMMENDED in RFC 3023.

There's a typo, sorry about that. I meant [draft-ietf-vcarddav-vcardxml-08].

> to RFC status but I would expect the RFC editor to take care of that.

Yes, that is my expectation also.

> cess contact information" or something like that.

I will update this to read:

   Applications which use this media type:  Applications that currently
      make use of the text/vcard media type can use this as an
      alternative. In general, applications that maintain or process
      contact information can use this media type.

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Apr 2011 16:36:36 -0400

> See OpenXPS, SVG, or MathML recent registrations that you could follow for the how-to.

May I pick "application/vcard+xml" as clipboard name?

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Apr 2011 16:49:29 -0400

> May I pick "application/vcard+xml" as clipboard name?

After reading a bit more on this, I have a few more questions...

- Is this something that users will see?
  - If so, why not simply add a "Descriptive Name" field to the media
type registration? This doesn't seem specific to clipboards to me...

- Why does it need to be part of the media type registration? Why does
it need to be registered at all?

Pointers to documentation would be very appreciated.

Thanks,
Simon

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 07 Apr 2011 22:55:34 +0200

>There's a typo, sorry about that. I meant [draft-ietf-vcarddav-vcardxml-08].

That would make the reference up to date, but there is still a missing
reference to RFC 3023 which notes

   These registrations SHOULD specify that the XML-based media type
   being registered has all of the security considerations described in
   RFC 3023 plus any additional considerations specific to that media
   type.

which does not seem to be met with either reference. If you update the
proposed registration with the changes you've mentioned, this largely
looks okay to me; for the benefit of other reviewers, it might be help-
ful to have an updated template with the changes applied (but do not go
out of your way producing it, these being mostly trivial changes).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 07 Apr 2011 23:02:40 +0200

>Pointers to documentation would be very appreciated.

If you do not know, and nobody can show, that all implementations of the
"application/vcard+xml" format that also support some kind of clipboard
use "..." as the clipboard name, I do not think you should include any-
thing about clipboard names and let others sort that out. Formally, this
information is not needed. (And no, at least on Windows users would not
see what I think is meant by "clipboard name").
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Chris Lilley <[email-masked]>
Date: Fri, 8 Apr 2011 03:04:43 +0200

On Thursday, April 7, 2011, 10:27:07 PM, Simon wrote:

>> coding, which has interoperability and security implications.

SP> I will update this to read:

SP>    Optional parameters: charset as defined for application/xml in
SP>       [RFC3023]; per [RFC3023], use of the charset parameter with the
SP>       value "utf-8" is "STRONGLY RECOMMENDED"

That verbatim quote from RFC3023 will probably suffice to deal with Bjoern's criticism, but as I just pointed out in another message to this thread his criticism is outdated and unwarranted, and raises security issues (as he himself points out).

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

---

From: Chris Lilley <[email-masked]>
Date: Fri, 8 Apr 2011 03:02:28 +0200

On Thursday, April 7, 2011, 10:12:00 PM, Bjoern wrote:

>>   Optional parameters:  none

BH> If you do not specify an optional 'charset' parameter, it is ambiguous
BH> what the encoding of `application/vcard+xml;charset=...` is; 

Or not; the XML specification amply covers how to determine the encoding of an XML document.

BH> if you only
BH> read the registration you are likely to ignore the parameter, 

The registration says there is no such parameter. Nor is it required for the application/* tree.

BH> while, if
BH> you read RFC 3023 you expect the 'charset' parameter to specify the en-
BH> coding, which has interoperability and security implications.

Considerations which don't arise if there is no such parameter, such as in this registration request.

Which is why the Technical Architecture group recommends against such use:
  "a receiving application can, with very high reliability, determine the encoding of an XML document by reading it, without reference to any external headers "

and

  "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction to use the charset is misplaced for application/xml and for non-text "+xml" types."

http://www.w3.org/2001/tag/2002/0129-mime#char-encoding

BH> If this omission of the parameter is not an oversight, I would expect a
BH> rationale for its omission as part of the review request and expect the
BH> interoperability and security issues that arise from this to be noted in
BH> the specification.

Perhaps you can point to which part of the Internet Media types registration process *requires* a charset parameter for the application/* tree and why adding one would be a good idea when, as you point out, adding a charset parameter and expecting it to overide the encoding declared in the XML instance has poor interoperability and raises security worries as well.

In other words, I strongly suspect that the 'omission' of this problematic parameter is not an oversight but a rational technical decision.

(Omitting comments with which I agree).

---

From: Paul Libbrecht <[email-masked]>
Date: Fri, 8 Apr 2011 08:53:35 +0200

>> May I pick "application/vcard+xml" as clipboard name?

I believe most Unix window-managers accept media types as clipboard names... I have no visible evidence yet.
I think not on Windows.
	http://msdn.microsoft.com/en-us/library/ms649013.aspx
On Mac, it should be a UTI.
	http://developer.apple.com/mac/library/documentation/FileManagement/Conceptual/understanding_utis/

> - Is this something that users will see?

they would see the *effect* of that only, that an application picks the right flavour (e.g. not the vcard's plain text).

> type registration? This doesn't seem specific to clipboards to me...

No, there's no intent to create a user language here.

> - Why does it need to be part of the media type registration? Why does it need to be registered at all?

So that applications that don't coordinate beforehand are still able to interoperate writing to and reading from the clipboard.

> Pointers to documentation would be very appreciated.

See above.

As for examples:
SVG:
  http://www.ietf.org/mail-archive/web/ietf-types/current/msg01147.html
  http://www.w3.org/TR/SVG/mimereg.html
MathML:
  http://www.w3.org/TR/MathML3/appendixb.html

paul

---

From: Simon Perreault <[email-masked]>
Date: Fri, 08 Apr 2011 09:06:16 -0400

On 2011-04-07 21:04, Chris Lilley wrote:
>>> If you do not specify an optional 'charset' parameter, it is
>>> ambiguous what the encoding of
>>> `application/vcard+xml;charset=...` is; if you only read the
>>> registration you are likely to ignore the parameter, while, if 
>>> you read RFC 3023 you expect the 'charset' parameter to specify
>>> the en- coding, which has interoperability and security
>>> implications.
> 
> SP>    Optional parameters: charset as defined for application/xml
> in SP>       [RFC3023]; per [RFC3023], use of the charset parameter
> with the SP>       value "utf-8" is "STRONGLY RECOMMENDED"
> 
> That verbatim quote from RFC3023 will probably suffice to deal with
> Bjoern's criticism, but as I just pointed out in another message to
> this thread his criticism is outdated and unwarranted, and raises
> security issues (as he himself points out).

So it looks like an update to RFC3023 would be needed?

In the meantime I think I'll go with the current consensus (RFC3023).

Thanks!
Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 08 Apr 2011 09:11:43 -0400

On 2011-04-07 16:55, Bjoern Hoehrmann wrote:
> for the benefit of other reviewers, it might be help-

Here you go:

   Type name:  application

   Subtype name:  vcard+xml

   Security considerations:  This media type has all of the security
      considerations described in [RFC3023], plus those listed in
      Section 7 of [draft-ietf-vcarddav-vcardxml-09].

   Interoperability considerations:  This media type provides an
      alternative syntax to vCard data [draft-ietf-vcarddav-vcardrev-18]
      based on XML.

   Published specification:  [draft-ietf-vcarddav-vcardxml-09]

   Additional information:

      Magic number(s):  none

      File extension(s):  XML data should use ".xml" as the file
         extension.

   Intended usage:  COMMON

   Author:  Simon Perreault

   Change controller:  IETF

Simon