Subject: [Enum] Submission of new I-D regarding ENUM on mobile-web

From: "Sungwoo Shin" <[email-masked]>
Date: Wed, 06 Jul 2005 02:18:33 -0400

Dear ENUM WG members 
 
My colleagues and I am working on new Internet draft
regarding ENUM usage on mobile terminal.  
Alsp Mr. Conroy made contribution on this new I-D.
 
This draft concerns registration of mobile web-service 
 
using URI scheme according to the guideline in RFC3761. 
 
The number of mobile Internet users keeps growing 
and ENUM will be important service of mobile Internet. 
 
Currently mobile web-services are provided in three
different ways. WAP, ME and i-Mode. 
The document registers mobile web-service(mobiweb)
as ENUMservices on three protocols.   
I am attaching presentation and draft. 
 
We expect to hear your precious comment and advice
to reflect on the document before discussion in Paris
meeting.   
 
All the best
 
Sungwoo Shin 
---------------------------------------------Sungwoo ShinResearch 
& Development TeamKorea Network Information CenterNational Internet 
Development Agency of KoreaOffice : +82-2-2186-4546Fax    
: 
+82-2-2186-4496---------------------------------------------
ENUM                                                          Jongyun Ra
Internet-Draft                                              Sungwoo Shin
Expires :                                                     Yongwan Ju
                                                                Weon Kim        
                                                                    NIDA
                                                               L. Conroy
                                                                    RMRL
                                                            July 6, 2005

             IANA Registration for ENUMservice Mobile Webpage
                   <draft-ra-shin-enum-mobileweb-00>

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on , 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document registers the ENUMservice "mobweb" using the URI
   schemes 'http:' and 'https:' as per the IANA registration process
   defined in the ENUM specification RFC3761. 

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Current Status of Mobile Web Service . . . . . . . . . . . . .  3
   4.  Mobile Web Service Registration  . . . . . . . . . . . . . . .  4
     4.1   Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2   Diverse Mobile Web Services Registration . . . . . . . . .  4
     4.3   Uniform Mobile Web Service Registration. . . . . . . . . .  5
   5. Considerations for the 'WAP' registration . . . . . . . . . . .  5
   6. Expected Behavior . . . . . . . . . . . . . . . . . . . . . . .  5
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     9.1   Normative References . . . . . . . . . . . . . . . . . . .  7
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . .  8

1.  Introduction

   ENUM (E.164 Number Mapping, RFC3761 [1]) is a system that transforms 
   E.164 numbers [12] into domain names and then uses DNS (Domain Name
   Service, RFC1034 [2]) services like delegation through NS records and
   NAPTR records to look up what services are available for a specific
   domain name. 
  
   This document registers 'Enumservices' according to the guidelines
   given in RFC 3761 [1] to be used for provisioning in the services
   field of an NAPTR [13] resource record to indicate what class of
   functionality a given end point offers.  The registration is defined
   within the DDDS (Dynamic Delegation Discovery System [3][4][5][6][7])
   hierarchy, for use with the "E2U" DDDS Application, defined in RFC 
   3761 [1].

   The following 'Enumservices' is registered with this document: 'mobileweb'.
   This document registers the ENUMservice "mobileweb" using the URI schemes
   'http:' and 'https:' as per the IANA registration process defined in the
   ENUM specification RFC3761. 

   ITU(International Telecommunication Union) made reports of world mobile
   usage, the total number of mobile subscribers has reached more than
   1.3 billion as of 2003 according to its statistics.   

   As the market of mobile telephony service has kept growing up, 
   the number of mobile internet users has been gradually increasing.

   Mobile ENUM usage will be of high importance according to its 
   convenience and portability.
       
   Mobile webpage is smaller and simpler than general webpage; 
   Mobile webpage is designed to be fitting in the pocket-sized display
   of mobile terminals.

   Mobile web services are being provided in different protocols.
   Currently there are three different protocols for the mobile
   web service : WAP[9], ME[10] and i-mode[11].

   This document registers mobile web-service(mobileweb) as ENUMservices
   according to the three protocols ; WAP, ME and i-mode.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [8].

3.  Current Status of Mobile Web Service

   Mobile Webpage is simplified form of general webpage to be displayed 
   in the small screen of Mobile Terminal. 
   
   Currently, there are three protocols for mobile terminal to access mobile
   web-pages. These three protocols are WAP(Wireless Application Protocol)[9],
   ME(Mobile Explorer)[10] and i-mode[11]. There are differences in the
   method for mobile terminal to request and receive a mobile webpage, and 
   the markup lanuage for mobile webpage.
   
   The followings are brief specifications of WAP, ME and i-mode.

  [WAP 1.x and 2.0]
  ------------           ---------------------------            ------------
  |   Device  |          |        WAP Gateway       |           |Web Server |
  ------------           ---------------------------            ------------ 
  |    WSP    | Encoded  |     WSP     |            |           |           |
  ------------    WML    --------------     HTTP    |    WML    |    HTTP   |
  |    WTP    |   Page   |     WTP     |            |    Page   |           |
  ------------  <------- ---------------------------  <--------  ------------
  |    WTLS   |          |     WTLS    |     SSL    |           |    SSL    | 
  ------------           ---------------------------            ------------            
  |    WDP    |          |     WDP     |     TCP    |           |    TCP    |
  ------------           ---------------------------            ------------   
  |   Bearer  |          |    Bearer   |     IP     |           |    IP     |
  ------------           ---------------------------            ------------

  [WAP 2.0 only]
  ------------                                                  ------------
  |   Device  |                                                 |Web Server |
  ------------                                                  ------------ 
  |  WP HTTP  |                                                 |   HTTP    |
  ------------   WML or  ---------------------------   WML or   ------------
  |    TLS    | XHTML MP |        WAP Proxy         | XHTML MP  |    TLS    |
  ------------   Page    ---------------------------    Page    ------------
  |   WP TCP  | <------- |    WP TCP   |     TCP    | <-------- |    TCP    | 
  ------------           ---------------------------            ------------            
  |     IP    |          |      IP     |     IP     |           |     IP    |
  ------------           ---------------------------            ------------   
  |  Wireless |          |   Wireless  |   Wired    |           |   Wired   |
  ------------           ---------------------------            ------------

  [ME]
  ------------                                                  ------------
  |   Device  |                                                 |Web Server |
  ------------                                                  ------------ 
  |    HTTP   |                                                 |   HTTP    |
  ------------ m-HTML or --------------------------- m-HTML or  ------------
  |  SSL/TLS  |   WML    |           G/W            |    WML    |    SSL    |
  ------------   Page    ---------------------------    Page    ------------
  |    TCP    | <------- |     TCP     |     TCP    | <-------- |    TCP    | 
  ------------           ---------------------------            ------------            
  |     IP    |          |      IP     |     IP     |           |     IP    |
  ------------           ---------------------------            ------------   
  |  Wireless |          |   Wireless  |   Wired    |           |   Wired   |
  ------------           ---------------------------            ------------
 
  [i-mode]
  ------------                                                  ------------
  |   Device  |                                                 |Web Server |
  ------------                             ----------------     ------------ 
  |    HTTP   |                            |     M-PGW    |     |    HTTP   |
  ------------                             ---------------- c-  ------------ 
  |    TLS    |c-HTML               c-HTML |  TLS  | TLS  | HTML|    TLS    |
  ------------ Page ----------------- Page ---------------- Page------------ 
  |     TL    |<----|      PPM       |<----|   TL  | TCP  |<----|    TCP    |
  ------------      -----------------      ----------------     ------------ 
  |  CallCtl  |     |CallCtl|IP(PMAP)|     |IP(PMAP)|  IP |     |     IP    |
  ------------      -----------------      ----------------     ------------ 
  | Wireless  |     |Wireless|Wired  |     | Wired |Wired |     |   Wired   |
  ------------      -----------------      ----------------     ------------ 

   Without special application support, Mobile webpage does not be displayed
   properly on other terminals like desktop and laptop than mobile terminal.
   Likewise, general webpage does not be displayed properly on mobile terminals.
   
   If mobile web-serivce is registered as ENUMServices in accordance with 
   RFC4002(IANA Registration for ENUMServices web and ft), it is very hard
   for a mobile service provider, terminal and its user to distinguish
   mobile webpage from general webpage. Moreover, there is no way to discriminate
   the protocol(WAP, ME or i-mode) of mobile web-service to be supported by the
   terminal.
   
   Consequently, the ENUMservices registration of mobile web-service must
   be classified according to the protocol of it and use other registration than
   RFC 4002.
      
4.  Mobile Web Service Registration

4.1   Introduction

   The Enumservices registered in this section indicate that the resource
   identified by the associated URI is capable of being a source of
   information through a mobile webpage.
 
   There are two choices of ENUMservices registration of mobile web-service.
   They are 'Diverse Mobile Web Service Registration' and 'Uniform Mobile
   Web Service Registration'.

   'Diverse Mobile Web Service Registration' uses Enumservice Type 'mobileweb'
   and different Enumservice Subtypes according to the protocols(WAP, ME,
   i-mode) of mobile web-service. So far, for those Enumservices that have
   both a type and subtype, the type reflected the kind of service provided,
   and the subtype reflected the URI scheme needed. However, this document
   specifies the protocols of mobile web-service as the subtype because it is
   impossible to discern among the protocols of mobile web-service through
   specifying URI scheme as the subtype(for example, ME and i-mode use the same
   URI scheme, http(s)). As you can see in '2.4.2.1 ENUM Services' of RFC 3761,
   Enumservice specifications contain the functional specification, the valid
   protocols, and the URI schemes that may be returned. There is no implicit
   mapping between the textual string "type" or "subtype" in the grammar for
   the Enumservice and URI schemes or protocols. Accordingly, it is not
   wrong to specify the protocols of mobile web-service as the subtype.
   If there is one mobile web-site, and the mobile web-service is provided
   using different URIs according to the protocols of mobile web-service, then
   the mobile web-service provider uses 'Diverse Mobile Web Service
   Registration'

   On the other hand, 'Uniform Mobile Web Service Registration' uses
   Enumservice Type 'mobileweb' but does not use any Enumservice Subtypes.
   If there is one mobile web-site, and the mobile web-service is
   provided using a same URI regardless of the protocols of mobile web-service
   (namely, if mobile web-server is intelligent and able to branch the
   connection to the proper web-page according to the supported protocol of
   mobile web-service), then the mobile web-service provider uses 'Uniform
   Mobile Web Service Registration'  

   Besides, in accordance with the trend that the protocols of mobile
   web-service are being unified and converged, this document proposes that
   the unified and converged mobile web-service be registered using 'Uniform
   Mobile Web Service Registration'.
   
4.2 Diverse Mobile Web Service Registration with 'http:','https:'

   Enumservice Name: "mobileweb"

   Enumservice Type: "mobileweb"

   Enumservice Subtype: "wap", "me", "imode"

   URI Scheme: 'http:', 'https'

   Functional Specification:
   
   This Enumservice indicates that the resource identified by the associated
   URI scheme is capable of being a source of information through a mobile
   webpage.
   
   Security Considerations:

   There are no specific security issues with this 'Enumservice'. However,
   the general considerations of Section 7 apply.
   
   Intended Usage: COMMON

   Author:

   Weon Kim, YongWan Ju, JongYun Ra (for author contact detail, see the
   Authors' Addresses section)

   Any other information the author deems interesting:

   None
   
4.3 Uniform Mobile Web Service Registration with 'http:','https:'

   Enumservice Name: "mobileweb"

   Enumservice Type: "mobileweb"

   Enumservice Subtype: N/A

   URI Scheme: 'http:', 'https'

   Functional Specification:
   
   This Enumservice indicates that the resource identified by the associated
   URI scheme is capable of being a source of information through a mobile
   webpage.
   
   Security Considerations:

   There are no specific security issues with this 'Enumservice'. However,
   the general considerations of Section 7 apply.
   
   Intended Usage: COMMON

   Author:

   Weon Kim, YongWan Ju, JongYun Ra (for author contact detail, see the Authors'
   Addresses section)
   
5. Considerations for the 'WAP' registration

   In 4.2, mobile web-service conforming to WAP protocol is registered with
   'http(s)' URI scheme. As you can see in the brief WAP specification above,
   for WAP 2.0, it is reasonable to use 'http(s)' URI scheme, while it might look
   unreasonable to use 'http(s)' URI scheme for WAP 1.x because WAP 1.x uses
   WSP/WTP for transport on terminal-side. However, it is noted that the terminal
   has a function that transforms http(s) requests in the browser(application) level
   to WSP/WTP forms, and WAP Gateway has a function that restores the WSP/WTP
   forms to the original http(s) requests again. Therefore, the fact that
   mobile web-service conforming to WAP is registered with 'http(s)' URI scheme
   doesn't make any issue. However, if a URI scheme(e.g wap, wsp, wtp, wsl and so on)
   for WAP would be devised in the future, mobile web-service conforming to WAP
   could be registered with the new URI scheme.    

6. Expected Behavior

   Browser(application) for mobile web-services and its user must know what
   protocol of mobile web-services is supported. Only so, it is possible
   to register and connect to a web-service properly.

   After a ENUM resolution of a E.164 associated with mobile web-service,
   there are three likely results.

   In case that only URIs registered by 'Diverse Mobile Web Service Registration'
   are returned as the resolution result, browser(application) or its user
   selects the URI registered by a proper Enumservice Subtype(wap, me or imode)
   and tries making connection with the URI. If there are several proper URIs,
   browser(application) or its user can select a URI, based on the value of Order
   and Preference field of NAPTR or the own rule.   

   In case that only URIs registered by 'Uniform Mobile Web Service Registration'
   are returned as the resolution result, browser(application) or its user
   selects a URI, based on the value of Order and Preference field of NAPTR or 
   the own rule. If the mobile web-server connected is intelligent and has an
   appropriate branch web-page, browser(application) and its user can be provided
   with mobile web-service. If the mobile web-server connected is intelligent
   and has no appropriate branch web-page, browser(application) and its user can
   not be provided with mobile web-service. If mobile web-service uses
   only the unified and converged protocol, and browser(application) supports it,
   browser(application) and its user can be provided with the mobile web-service.
   If mobile web-service uses only the unified and converged protocol, 
   and browser(application) does not support it, browser(application) and its user
   can not be provided with the mobile web-service.

   In case that URIs registered by 'Diverse Mobile Web Service Registration' and
   URIs registered by 'Uniform Mobile Web Service Registration' are returned
   simultaneoustly as the resolution result, browser(application) or its user
   must select preferentially a URI registered by 'Diverse Mobile Web Service
   Registration', based on the value of Order and Preference field of NAPTR or the
   own rule because it gurantees that browser(application) and its user
   are provided with mobile web-service. If there is no proper URI registered
   by 'Diverse Mobile Web Service Registration', browser(application) or its user
   can select a URI registered by 'Uniform Mobile Web Service Registration', based
   on the value of Order and Preference field of NAPTR or the own rule.    
   If the mobile web-server connected is intelligent and has an appropriate branch
   web-page, browser(application) and its user can be provided with mobile web-service.
   If the mobile web-server connected is intelligent and has no appropriate
   branch web-page, browser(application) and its user can not be provided with
   mobile web-service. If mobile web-service uses only the unified and converged
   protocol, and browser(application) supports it, browser(application) and
   its user can be provided with the mobile web-service. If mobile web-service
   uses only the unified and converged protocol, and browser(application) does
   not support it, browser(application) and its user can not be provided with the
   mobile web-service.

7.  Security Considerations

   As used by ENUM, DNS is a global, distributed database.  Thus any
   information stored there is visible to anyone anonymously.  Although
   this is not qualitatively different from publication in a telephone
   directory, it does expose the data subject to having "their"
   information collected automatically without any indication that this
   has been done, or by whom.

   Data harvesting by third parties is often used to generate lists of
   targets for unrequested information; in short, it is used to address
   "spam".  Anyone who uses a Web-archived mailing list is aware that
   the volume of "spam" email they receive increases when they post to
   the mailing list; publication of a telephone number in ENUM is no
   different and may be used to send "junk faxes" or "junk SMS", for
   example.

   Many mailing list users have more than one email address and use
   "sacrificial" email accounts when they post to these lists to help
   filter out unrequested emails.  This is not so easy with published
   telephone numbers; the PSTN E.164 [12] number assignment process is much
   more involved, and usually a single E.164 number (or a fixed range of
   numbers) is associated with each PSTN access.  Thus, providing a
   "sacrificial" phone number in any publication is not possible.

   Due to the implications of publishing data on a globally accessible
   database, as a principle the data subject MUST give explicit informed
   consent when data is published in ENUM.

   In addition, the data subject should be made aware that, due to
   storage of such data during harvesting by third parties, removal of
   the data from publication will not remove any copies that have been
   taken; in effect, any publication may be permanent.

   However, regulations in many regions will require that the data
   subject can at any time request that the data is removed from
   publication, and that consent for its publication is explicitly
   confirmed at regular intervals.

   The user SHOULD be asked to confirm opening a mobile webpage because
   it could impose a charge on the user.

   Using 'http' URI scheme to connect with a mobile webpage is not secure,
   so the user should apply the same caution when entering personal data
   as they would do if using a client application started with any other
   method.
   Although this is not a feature of ENUM or these Enumservices, the
   ENUM-using application on the end system may appear different from
   the user's "normal" browser, so the user SHOULD receive an indication
   of whether their communication is secured.

   As evaluating a mobile web page can involve execution of embedded (or
   linked) content that may include executable code, evaluating a mobile web
   URL involves risks.  If automatic evaluation of a mobile web link were
   to be used, the querying user would be exposed to risks associated with
   that automatic download and execution of content.  Thus, the client
   MUST ask the querying user for confirmation before evaluating the mobile 
   web URL; the client MUST NOT download and evaluate the mobile web content
   automatically.

   An analysis of threats specific to the dependence of ENUM on the DNS,
   (threats against which are covered in [14]) and the applicability of
   DNSSEC to these, is provided in RFC 3761.
   
8.  IANA Considerations

   This document registers the 'mobileweb' ENUMservice according to
   specifications and guidelines in RFC 3761 and the definitions in this
   document.

9.  References

9.1.  Normative References

   [1]   Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
         Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
         Application (ENUM)", RFC 3761, April 2004.
         
   [2]   Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
         1034, November 1987.
         
   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         One: The Comprehensive DDDS", RFC 3401, October 2002.

   [4]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Two: The Algorithm", RFC 3402, October 2002.

   [5]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.

   [6]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Four: The Uniform Resource Identifiers (URI)", RFC 3404,
         October 2002.

   [7]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405,
         October 2002.
         
   [8]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [9]   Wireless Application Protocol[WAP] http://www.wapforum.org
   
   [10]  Mobile Explorer[ME] http://www.microsoft.com
   
   [11]  i-mode http://www.nttdocomo.com
   
   [12]  ITU-T, "The International Public Telecommunication Number
         Plan", Recommendation E.164, May 1997.

   [13]  Mealling, M., "The Naming Authority Pointer (NAPTR) DNS Resource
         Record", RFC 2915, September 2000

Authors' Addresses
   
   YoungWan Ju
   National Internet Development Agency of Korea
   1321-11, Seocho2-dong, Seocho-gu, Seoul
   Korea

   Phone: +82-2-2186-4536
   EMail: ywju at nida.or.kr

   Sungwoo Shin
   National Internet Development Agency of Korea
   1321-11, Seocho2-dong, Seocho-gu, Seoul
   Korea

   Phone: +82-2-2186-4546
   EMail: ssw at nida.or.kr
   
   Jongyun Ra
   National Internet Development Agency of Korea
   1321-11, Seocho2-dong, Seocho-gu, Seoul
   Korea

   Phone: +82-2-2186-4599
   EMail: rajy at nida.or.kr

   Lawrence Conroy
   Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey
   United Kingdom

   Phone: +44-1794-833666
   Email: lwc at roke.co.uk
   URI:   http://www.sienum.co.uk

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr at ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.   
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 06 Jul 2005 15:49:47 -0400

<FONT face=Arial 
color=#0000ff size=2>Your draft appears to be missing an expiration date.  
185 days from today is 7 Jan 2006.  Recommend you add this to the next 
iteration of your draft as I think an expiration is a requirement for 
I-Ds.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Regards
<FONT face=Arial 
color=#0000ff size=2>Jason Livingood
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

  From: enum-bounces at ietf.org 
  [mailto:enum-bounces at ietf.org] On Behalf Of Sungwoo 
  ShinSent: Wednesday, July 06, 2005 2:18 AMTo: 
  enum at ietf.orgCc: YongWanJu; Conroy, Lawrence (SMTP); ??; 
  rajy at nic.or.krSubject: [Enum] Submission of new I-D regarding ENUM 
  on mobile-web

  Dear ENUM WG members 

   

   
   
  All the best
   
  Sungwoo Shin 
  ---------------------------------------------Sungwoo ShinResearch 
  & Development TeamKorea Network Information CenterNational 
  Internet Development Agency of KoreaOffice : 
  +82-2-2186-4546Fax    : 
  +82-2-2186-4496---------------------------------------------
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Sungwoo Shin" <[email-masked]>
Date: Thu, 07 Jul 2005 19:12:35 -0400

Dear members and colleagues
 
I had already some feedback from colleagues and the IETF 
secretariat  
and reflected on the draft.  I am attaching the recently 
corrected one. 
 
Thanks for your cooperation and I am looking forward to hearing
any comment on this.
 
Sungwoo Shin 
 
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  ----- Original Message ----- 
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt &#xAD74;&#xB9BC;; font-color: black">From: <A 
  title=ssw at nic.or.kr href="mailto:ssw at nic.or.kr">Sungwoo Shin 
  To: <A title=enum at ietf.org 
  href="mailto:enum at ietf.org">enum at ietf.org 
  Cc: <A title=ywju at nic.or.kr 
  href="mailto:ywju at nic.or.kr">YongWanJu ; <A title=rajy at nic.or.kr 
  href="mailto:rajy at nic.or.kr">rajy at nic.or.kr ; <A title=lwc at roke.co.uk 
  href="mailto:lwc at roke.co.uk">Conroy, Lawrence (SMTP) ; <A 
  title=wkim at nic.or.kr href="mailto:wkim at nic.or.kr">&#xAE40;&#xC6D0; 
  Sent: Wednesday, July 06, 2005 3:18 PM
  Subject: Submission of new I-D regarding 
  ENUM on mobile-web

  Dear ENUM WG members 

   

   
   
  All the best
   
  Sungwoo Shin 
Expires : January 7, 2006                                     Yongwan Ju
                                                                Weon Kim        
                                                                    NIDA
                                                               L. Conroy
                                                                    RMRL
                                                            July 6, 2005

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   This Internet-Draft will expire on January 7, 2006.

Copyright Notice

Abstract

   This document registers the ENUMservice "mobileweb" using the URI
   schemes 'http:' and 'https:' as per the IANA registration process
   defined in the ENUM specification RFC3761. 

Table of Contents

1.  Introduction

       

2.  Terminology

   

  [WAP 1.x and 2.0]

  [WAP 2.0 only]

  [ME]
 
  [i-mode]

   

4.1   Introduction

   

   
   
   Security Considerations:

   Intended Usage: COMMON

   Author:

   JongYun Ra, Sungwoo Shin, Yongwan Ju, Weon Kim, Lawrence conroy
   (for author contact detail, see the Authors' Addresses section)

   None

   Enumservice Subtype: N/A

   
   
   Security Considerations:

   Intended Usage: COMMON

   Author:

   JongYun Ra, Sungwoo Shin, Yongwan Ju, Weon Kim, Lawrence conroy
   (for author contact detail, see the Authors' Addresses section)

6. Expected Behavior

   simultaneously as the resolution result, browser(application) or its user

   
8.  IANA Considerations

9.  References

         

         

   

Authors' Addresses
   
   YoungWan Ju

   Phone: +82-2-2186-4536

   Sungwoo Shin

   Phone: +82-2-2186-4546
   EMail: ssw at nida.or.kr
   
   Jongyun Ra

   Phone: +82-2-2186-4599

   Lawrence Conroy
   Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey
   United Kingdom

   Phone: +44-1794-833666
   Email: lwc at roke.co.uk

Disclaimer of Validity

Copyright Statement

Acknowledgment

---

From: "Russell, Nick, VF UK - Technology \(TS\)" <[email-masked]>
Date: Mon, 11 Jul 2005 04:46:33 -0400

<FONT face=Arial 
color=#0000ff size=2>Dear Sungwoo,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>I'm fairly new to this IETF list, so please bear with me 
while I clarify some things.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>I've just read your draft and would like to 
clarify what it is you are proposing. Is it a method for the 
network for determining device capability i.e. when a device asks 
for a web page (by sending an HTTP request), the network operator performs an 
ENUM look-up on the E.164 number of the device, in order to determine how to 
serve the HTTP request? Or is it that you want to be able to enable devices to 
operate as "web servers" themselves and so allow for more seamless 
device-to-device communication? I'm thinking it's the former, but would just 
like to clarify before providing any feedback.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Thanks,
<FONT face=Arial 
color=#0000ff size=2>Nick
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

  From: enum-bounces at ietf.org 
  [mailto:enum-bounces at ietf.org] On Behalf Of Sungwoo 
  ShinSent: 08 July 2005 00:12To: 
  enum at ietf.orgSubject: [Enum] Re: Submission of new I-D regarding 
  ENUM on mobile-web

   
   
  Sungwoo Shin 
   
  <BLOCKQUOTE dir=ltr 
    ----- Original Message ----- 
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt &#xAD74;&#xB9BC;; font-color: black">From: 
    Sungwoo Shin 
    Sent: Wednesday, July 06, 2005 3:18 
    PM

    Dear ENUM WG members 

     

     
     
    All the best
     
    Sungwoo Shin 
    ---------------------------------------------Sungwoo 
    ShinResearch & Development TeamKorea Network Information 
    CenterNational Internet Development Agency of KoreaOffice : 
    +82-2-2186-4546Fax    : 
    +82-2-2186-4496---------------------------------------------
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum