IANA Registration for Enumservices email, fax, mms, ems, and sms
draft-ietf-enum-msg-05

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART

Version -04 satisfies my concerns about references for mailed *MS messages, and has also addressed the reviewer's significant commment.

[Note]: '- Hayes reviewed and found no problem with sms/mms/ems (3GPP
material) in here (Jul 2004)
- RFC Editor note for problem with abstract.  Submitted before IPR cutoff.' added by Amy Vezza

[Ballot discuss]
This memo specifies how to show that a participant can receive an SMS, EMS or MMS message using the phone system or by email.

However, I cannot see that it points to a specification of how to package an SMS, MMS or EMS message inside an email message.

Since images have many different ways of being encoded in an email message, and not all clients have support for all image formats, having some common mapping would maximize interoperability.

Possible resolution 1: Point to a definition.
Possible resolution 2: Delete the mailto: URL mapping

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART

Significant comment:

2. Section 4. Security Considersations section needs rewording. Propose to change from:
 
  " An fax number as any other phone number may give not so much privacy
  away then a name in the format user@host (e.g. an email or sip
  address), but there is still the risk of unwanted messages."

to something like:
 
  "Although a fax number, like other E.164 numbers, doesn't appear to reveal as
  much identity information about a user
  as a name in the format user@host (e.g. an email or sip
  address), the information is still publicly available, thus there is still
  the risk of unwanted communication."

[Ballot comment]
This document uses "e-mail" and "email."  Please pick one spelling.

  Please remove the references ([6]) from the Abstract.

  Section 2 says:
  >
  > The services specified here are intended NOT to specify the protocol
  > or even method of connection that MUST be used to achieve each
  > service.
  >
  I do not understand the use of RFC 2119 language here.  It is unclear to
  me what an implementation MUST or MUST NOT do.  What would appear in an
  implementation report regarding this sentence?

[Ballot comment]
Section 3:
To reduce spam and
other unwanted communication other means should be made available.

"Other means" of what?

The security considersations for sections 3 and 4 are subsumed by
section 6; there should just be pointers, as is done for section 5.

MUST cite RFC 3833 in the Security
Considerations

[Ballot discuss]
The fax registration lists the URI scheme as "tel", but the same
document that registered "tel" (RFC 2806) also registered "fax".
If this document doesn't want to use "fax" for some reason,
it should explain why.

I'm also very concerned about the description of the relationships
among SMS, EMS, and MMS and the selected URI schemes.  The
document lists MMS as a superset of SMS, which may be true
in some environments but I am not sure it is necessarily true .
I'm also concerned about using a mailto: URI with MMS; the
two are related, but not interoperable.

The best case there is undoubtedly to register MMS, a process that
has been frustrated by the ongoing issues related to the revision
of 2717 and the collision with Microsoft's use of MMS.  While
I realize that is problematic, registering it with the wrong scheme
seems like a worse problem.

[Note]: '- Hayes reviewed and found no problem with sms/mms/ems (3GPP
material) in here (Jul 2004)
- RFC Editor note for problem with abstract.  Submitted before IPR cutoff.' added by Allison Mankin

When the rev came, it needed a re-rev because a sip: usage had been added
with no supporting spec (s/m/e MS to SIP).  Re-rev is Last Called.

[Note]: 'WG co-chair  supported re-spinning doc for title clarification and improved security considerations before IETF Last Call.
Still waiting for the revs after four months...' added by Allison Mankin

[Note]: 'WG co-chair  supported re-spinning doc for title clarification and improved security considerations before IETF Last Call.
Should be able to move this doc right after the New Year.' added by Allison Mankin

Revision draft is needed before it goes to the IESG:  include text about DNSSEC and split references.  The Last Call will be forwarded to LEMONADE for them to have a look at the sms/mms approach.  Good privacy considerations.