From mankin@psg.com Mon, 02 May 2005 07:49:02 -0400 From: Allison Mankin Date: Mon, 02 May 2005 07:49:02 -0400 To: "Stastny Richard" Subject: [Enum] AD Review: draft-ietf-enum-void - minor rev requested In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BE39@oefeg-s04.oefeg.loc> Message-ID: <200505011658.MAA02405@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Lawrence, draft-ietf-enum-void-00.txt is ready for IETF Last Call (and, I anticipate for the IESG) except for an editorial issue. It is minor, but it motivates a quick rev. This is just to expand NRA and CSP when they are first used. They have enough context when they appear (I think), just need the words. I wouldn't normally turn a document back for acronyms, but in this case, the reviewers of the spec can't check the careful way you've made sure the roles and usage are handled, unless they can read these words. Please just recycle and we'll be ready to roll. Allison _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rudolf.brandner@siemens.com Wed, 04 May 2005 12:59:24 -0400 From: Brandner Rudolf Date: Wed, 04 May 2005 12:59:24 -0400 To: enum at ietf.org Subject: [Enum] Test - Please ignore Message-ID: <79D5F4B2D775204D9C7852EE41C54773089A41BB@mchh2a1e.mchh.siemens.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi all, I am experiencing email problems, thus this test email. Please ignore. Sorry for any inconvenience, Rudi _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Thu, 05 May 2005 11:30:43 -0400 From: "Fullbrook Kim \(UK\)" Date: Thu, 05 May 2005 11:30:43 -0400 To: Subject: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices" ) Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624FDE009@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Title: Message Status: R Am getting confused over the status of these various registrations but thought it was worth clearing up what appears to be a mis-understanding over the relationship between MMS and SMS. For enumservices they should be considered as different services.    Previous emails (extracts from one of these below) mention MMS as a container for SMS which to me (and maybe to other readers as well) implies that the SMS service is a subset of MMS. Apologies to the author(s) if this point was not intended but having read the emails several times feel that this is one of the key points being implied. The clarification is to indicate that MMS and SMS are completely different services. SMS is not a subset of MMS. Their characteristics, capabilities, protocols (internal & external), tariffs are all different. There may be isolated circumstances in which some operators use an SMS to deliver an MMS but this is very much an exception and does not demonstrate that SMS is a subset of MMS.   The 3GPP references quoted are only talking about message formats and addressing: TS 23.140 section 5.1.3.1. Not sure which version of the spec is being quoted here. The latest version of the Release 5 spec is V5.11.0 and the relevant section is 5.1.2.1, not 5.1.3.1. This deals with message encapsulation and only specifies that MMS in certain circumstances uses an encapsulation format which is compatible with SMS. TS 23.140 section 8.3.2  This says that delivery of an MMS should use the same MSISDN (delivery address) as is used for SMS. 3GPP TS 26.140 section 4.1 talks about text formats in SMSs and MMS.   Kim Fullbrook O2 UK ---------------------------------- From a previous email: (ii) re. MMS as a "container" for SMS or EMS.       Here's something that was send last October as part of the IESG evaluation.       I repeat it here on the list:     "We understand from 3GPP TS 23.140 that an MMS Relay Proxy WILL be able to handle messages holding a plain text sub-part that carries SMS text, and that the MMS User Agent will be able to receive and process them  (see, for example, sections 5.1.3.1 and 8.3.2 of TS 23.140 and also section 4.1 of 3GPP TS 26.140).      It is also one of the high level requirements specified in TS 22.140 (section 4.1), where it is stated that:      - 'Regardless of the message type / format, MMS shall be capable of supporting integration of all types of messaging (e.g. fax, SMS, Multimedia , voicemail, e-mail etc.) in a consistent manner'.        We contend that this means that, if an end system is capable of sending an MMS towards the addressed destination URI, and if this message only includes plain text according to the SMS specifications (and as described in 23.140 and 26.140), the MMS system will be able to process that message. Thus MMS is a candidate for "upgrade" even if the end user prefers to send SMS only.        There *is* a tariff issue here, in that sending an MMS may be charged differently from sending an SMS; however, indication of the use of MMS rather than SMS is an issue for the end system, not for the protocol as such".        As I have stated before, there is an existence proof in that Mobile Operators *do* allow one to send are receive MMs with just a plain text part. The specifications spell out that this is a standard part of the MMS design. As such I have little choice but to assume that these systems follow the specifications rather than completely ignore them, or at least that they will be updated to reflect the specifications at some point if they are, as yet, non-compliant.     ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu, 05 May 2005 17:42:03 -0400 From: lconroy Date: Thu, 05 May 2005 17:42:03 -0400 To: "Fullbrook Kim (UK)" Subject: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices" ) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624FDE009@Uksthmsx012> Message-ID: <12e8f3baa4728d26a99eb122b88a7760@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi again Kim, folks, Re. status:: We will be updating MSG again shortly, so look for a new version next week. This is to reflect clarifications requested during IESG evaluation. It will go directly to the IESG for their review and we hope will clear any remaining questions. I trust that this next version will be ready to be approved, and then it will be released to the RFC-Editor for publication. The VOID draft will also be up-issued to add clarification of the Acronyms. We will up-issue the Experiences draft - this has been delayed whilst I check the behaviour of implementations of RegExp parsing functions - both I and my eagle-eyed co-author want this to be right. Finally, we will up-issue the VOVI draft for the group's reading (and, from experience, ranting) pleasure. To your comments:: -- This has been a LONG process, so the TS quoted in the current draft (and so the section numbers within the referenced documents) may well have drifted. This is an IETF standards track document, so we can only refer to documents that are officially released - the latest approved version of TS 23.140 for Release 5 is 5.9.0, according to the 3GPP document service. Likewise, the latest approved Release 5 version of TS 26.140 is 5.2.0. Sigh... A quick scan of TS 23.140 version 5.9.0 shows section 5.1.2.1 and 8.4.4 to be still current, and 26.140 version 5.2.0 still covers text media processing in section 4.1, but I'll check again to ensure that any section references are reasonable before up-issuing the draft. Thanks for the query. -- The MSG draft does specify the SMS & MMS registrations as separate Enumservices. -- We contend that it is possible to send an MMS containing only a plain text part. That's ALL we contend. As mentioned, a new version will be issued shortly (after I've re-checked the latest published versions of the referenced TSes, and added reference to the associated Lemonade MMS mapping draft which is also going through IESG Review). all the best, Lawrence On 5 May 2005, at 16:30, Fullbrook Kim (UK) wrote: Am getting confused over the status of these various registrations but thought it was worth clearing up what appears to be a mis-understanding over the relationship between MMS and SMS. For enumservices they should be considered as different services. Previous emails (extracts from one of these below) mention MMS as a container for SMS which to me (and maybe to other readers as well) implies that the SMS service is a subset of MMS. Apologies to the author(s) if this point was not intended but having read the emails several times feel that this is one of the key points being implied. The clarification is to indicate that MMS and SMS are completely different services. SMS is not a subset of MMS. Their characteristics, capabilities, protocols (internal & external), tariffs are all different. There may be isolated circumstances in which some operators use an SMS to deliver an MMS but this is very much an exception and does not demonstrate that SMS is a subset of MMS. The 3GPP references quoted are only talking about message formats and addressing: TS 23.140 section 5.1.3.1. Not sure which version of the spec is being quoted here. The latest version of the Release 5 spec is V5.11.0 and the relevant section is 5.1.2.1, not 5.1.3.1. This deals with message encapsulation and only specifies that MMS in certain circumstances uses an encapsulation format which is compatible with SMS. TS 23.140 section 8.3.2 This says that delivery of an MMS should use the same MSISDN (delivery address) as is used for SMS. 3GPP TS 26.140 section 4.1 talks about text formats in SMSs and MMS. Kim Fullbrook O2 UK ---------------------------------- From a previous email: (ii) re. MMS as a "container" for SMS or EMS. Here's something that was send last October as part of the IESG evaluation. I repeat it here on the list: "We understand from 3GPP TS 23.140 that an MMS Relay Proxy WILL be able to handle messages holding a plain text sub-part that carries SMS text, and that the MMS User Agent will be able to receive and process them (see, for example, sections 5.1.3.1 and 8.3.2 of TS 23.140 and also section 4.1 of 3GPP TS 26.140). It is also one of the high level requirements specified in TS 22.140 (section 4.1), where it is stated that: - 'Regardless of the message type / format, MMS shall be capable of supporting integration of all types of messaging (e.g. fax, SMS, Multimedia , voicemail, e-mail etc.) in a consistent manner'. We contend that this means that, if an end system is capable of sending an MMS towards the addressed destination URI, and if this message only includes plain text according to the SMS specifications (and as described in 23.140 and 26.140), the MMS system will be able to process that message. Thus MMS is a candidate for "upgrade" even if the end user prefers to send SMS only. There *is* a tariff issue here, in that sending an MMS may be charged differently from sending an SMS; however, indication of the use of MMS rather than SMS is an issue for the end system, not for the protocol as such". As I have stated before, there is an existence proof in that Mobile Operators *do* allow one to send are receive MMs with just a plain text part. The specifications spell out that this is a standard part of the MMS design. As such I have little choice but to assume that these systems follow the specifications rather than completely ignore them, or at least that they will be updated to reflect the specifications at some point if they are, as yet, non-compliant. ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Tue, 10 May 2005 15:59:20 -0400 From: Internet-Drafts@ietf.org Date: Tue, 10 May 2005 15:59:20 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-void-01.txt Message-ID: <200505101959.PAA08026@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-01.txt Pages : 15 Date : 2005-5-10 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-void-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-void-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 11 May 2005 11:55:05 -0400 From: "Stastny Richard" Date: Wed, 11 May 2005 11:55:05 -0400 To: Subject: [Enum] ETSI Documents on ENUM published Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BE7C@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear all, ETSI has finally published officially the two documents on ENUM already approved at the January 2005 TISPAN Plenary: ETSI TS 102 172 V1.2.1 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Minimum requirements for interoperability of ENUM implementations http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=20591 ETSI TR 102 055 V1.1.1 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); ENUM scenarios for user and infrastructure ENUM http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=19572 best regards Richard Stastny _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Wed, 11 May 2005 15:50:23 -0400 From: Internet-Drafts@ietf.org Date: Wed, 11 May 2005 15:50:23 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-msg-05.txt Message-ID: <200505111950.PAA13869@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-05.txt Pages : 21 Date : 2005-5-11 This document registers the Enumservices "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-msg-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-msg-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Wed, 11 May 2005 17:46:04 -0400 From: The IESG Date: Wed, 11 May 2005 17:46:04 -0400 To: IETF-Announce Subject: [Enum] Last Call: 'IANA Registration for Enumservice VOID' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for Enumservice VOID ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at ietf.org or ietf at ietf.org mailing lists by 2005-05-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-void-01.txt _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From klaus.darilion@nic.at Fri, 13 May 2005 10:41:54 -0400 From: "Klaus Darilion" Date: Fri, 13 May 2005 10:41:54 -0400 To: Subject: [Enum] Are these NAPTRs valid? Message-ID: <8BC845943058D844ABFC73D2220D46650233F101@nics-mail.sbg.nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi all! Can you please help me out with the follwing scenario: I have an ENUM domain. Two digit extensions should be forwarded to another proxy as three digit extensions. Thus I use the following NAPTRs: * NAPTR 100 10 "u" "E2U+sip" "!^\\+431234567(...)$!sip:e001-366\\1 at proxy1.at!" . * NAPTR 100 20 "u" "E2U+sip" "!^\\+431234567(..)$!sip:e002-\\1 at proxy2.at!" . IMO, the NAPTRs are fine. But I use an ENUM aware SIP proxy, which does not handle the two-digit extensions. Should the ENUM resolver also try the second NAPTR (as the regex of the first NAPTR does not match)? regards, Klaus _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Fri, 13 May 2005 21:08:27 -0400 From: lconroy Date: Fri, 13 May 2005 21:08:27 -0400 To: "Klaus Darilion" Subject: Re: [Enum] Are these NAPTRs valid? In-Reply-To: <8BC845943058D844ABFC73D2220D46650233F101@nics-mail.sbg.nic.at> Message-ID: <506d712006e912eb9fb7455022a91a06@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Klaus, Yes, it should (and yes, they are valid). Most ENUM-aware proxies are broken :( Remind the nic.at folk who are coming to the ENUM plugtest to bring this software and we'll torture it. With luck (and source), we may even find time to fix it, once we know what it does. all the best, Lawrence On 13 May 2005, at 15:41, Klaus Darilion wrote: Hi all! Can you please help me out with the follwing scenario: I have an ENUM domain. Two digit extensions should be forwarded to another proxy as three digit extensions. Thus I use the following NAPTRs: * NAPTR 100 10 "u" "E2U+sip" "!^\\+431234567(...)$!sip:e001-366\\1 at proxy1.at!" . * NAPTR 100 20 "u" "E2U+sip" "!^\\+431234567(..)$!sip:e002-\\1 at proxy2.at!" . IMO, the NAPTRs are fine. But I use an ENUM aware SIP proxy, which does not handle the two-digit extensions. Should the ENUM resolver also try the second NAPTR (as the regex of the first NAPTR does not match)? regards, Klaus --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mankin@psg.com Sun, 15 May 2005 12:54:50 -0400 From: Allison Mankin Date: Sun, 15 May 2005 12:54:50 -0400 To: lconroy Subject: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices" ) In-Reply-To: <12e8f3baa4728d26a99eb122b88a7760@insensate.co.uk> Message-ID: <200505151654.MAA08811@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Lawrence, Richard, Enum-folks, The IESG is now all clear on the enum-msg draft. Reviewing the exchange with Kim here, and the 05 draft: - The references now look like they are as good as IETF can get them. - The draft says precisely that an MMS can deliver an SMS, so a user can use the enumservices accordingly. It has given enough basis for this from the specifications. The draft contains a statement that there are potential tariff and other differences between the encapsulated usage and direct SMS. So my note is really just a heads-up that the approval will go forward during the next day or so. I believe the draft is all in order now. Allison _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sun, 15 May 2005 17:27:11 -0400 From: "Stastny Richard" Date: Sun, 15 May 2005 17:27:11 -0400 To: Subject: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices") Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BE9D@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Allison, thank you for progressing the draft within the IESG. Now let's hope that the linked I-D http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-03.txt is going forward soon as well. regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Allison Mankin Gesendet: So 15.05.2005 18:54 An: lconroy Cc: enum at ietf.org Betreff: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices") Lawrence, Richard, Enum-folks, The IESG is now all clear on the enum-msg draft. Reviewing the exchange with Kim here, and the 05 draft: - The references now look like they are as good as IETF can get them. - The draft says precisely that an MMS can deliver an SMS, so a user can use the enumservices accordingly. It has given enough basis for this from the specifications. The draft contains a statement that there are potential tariff and other differences between the encapsulated usage and direct SMS. So my note is really just a heads-up that the approval will go forward during the next day or so. I believe the draft is all in order now. Allison _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mankin@psg.com Sun, 15 May 2005 23:33:38 -0400 From: Allison Mankin Date: Sun, 15 May 2005 23:33:38 -0400 To: "Stastny Richard" Subject: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices") In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BE9D@oefeg-s04.oefeg.loc> Message-ID: <200505160333.XAA23935@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, > Now let's hope that the linked I-D > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-03.txt Yes, I'll be keeping my eye on that draft's approval and progress. Allison _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From iesg-secretary@ietf.org Mon, 16 May 2005 15:39:33 -0400 From: The IESG Date: Mon, 16 May 2005 15:39:33 -0400 To: IETF-Announce Subject: [Enum] Protocol Action: 'IANA Registration for Enumservices email, fax, mms, ems and sms' to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The IESG has approved the following document: - 'IANA Registration for Enumservices email, fax, mms, ems and sms ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document registers the enumservice 'email', 'fax', 'sms', 'ems' and 'mms' using the URI schemes 'tel:' and 'mailto:' following the IANA registration process defined in the ENUM specification RFC 3761. In each case, the enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message of the technology in that service (email, fax, sms, ems, or mms). The draft also describes the privacy risks of these enumservices. Working Group Summary The Working Group supported this document. During the IESG review, there was a renewed working group discussion of the references and background concerning SMS, EMS and MMS, which was resolved. Protocol Quality A Last Call review of the document produced a comment that it should mention the risks of publication of some information due to the costs incurred when SMS/EMS/MMS are received (this is distinct from the privacy issue). Since SMS/EMS and MMS are not IETF technology, the 3GPP liaison to the IETF, Stephen Hayes, gave a brief but positive review of the document. The IESG reviews of the document found it needed better documentation of the services reached with mailto, and this was provided. Allison Mankin was the IESG's responsible Area Director. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 20 May 2005 11:39:16 -0400 From: Richard Shockey Date: Fri, 20 May 2005 11:39:16 -0400 To: enum at ietf.org Subject: [Enum] ENUM WG - 63th IETF WG/BOF Scheduling Message-ID: <6.2.1.2.2.20050520094959.04254eb0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Well its that time to start thinking about requests for time at the WG meeting. We're particularly interested in status of Operational Experiences. etc. The chairs have requested a full 2 1/2 hour slot. We anticipate dividing that time into two parts. One hour for normal WG business and status of current drafts. 1 1/2 hour for discussion of a forthcoming draft on Infrastructure ENUM. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mankin@psg.com Fri, 27 May 2005 13:49:48 -0400 From: Allison Mankin Date: Fri, 27 May 2005 13:49:48 -0400 To: "Stastny Richard" Subject: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices") In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BE9D@oefeg-s04.oefeg.loc> Message-ID: <200505271749.NAA05248@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi, Richard, Just to let you know, I see in the tracker the lemonade MMS Mapping draft has just been approved (cleared its Discusses). So the MSG enumservice will now be able to have its RFC published without a long wait for this normative dependency. Allison > thank you for progressing the draft within the IESG. > Now let's hope that the linked I-D > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-03.txt > is going forward soon as well. > > regards > Richard > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Allison Mankin > Gesendet: So 15.05.2005 18:54 > An: lconroy > Cc: enum at ietf.org > Betreff: Re: [Enum] MMS and SMS (was "(Non)-Progress of certain = > Enumservices") > > > > Lawrence, Richard, Enum-folks, > > The IESG is now all clear on the enum-msg draft. > > Reviewing the exchange with Kim here, and the 05 draft: > > - The references now look like they are as good as IETF > can get them. > > - The draft says precisely that an MMS can deliver an SMS, so a user > can use the enumservices accordingly. It has given enough > basis for this from the specifications. The draft contains > a statement that there are potential tariff and other differences > between the encapsulated usage and direct SMS. > > So my note is really just a heads-up that the approval will go forward > during the next day or so. I believe the draft is all in order now. > > Allison > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum