rfc2604.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,581 行 · 第 1/5 页

5.4.  Intellectual Property Issues

    There are no known intellectual property issues with the ACAP
    solution.  The ACAP specification was developed within the IETF, and
    no ownership, patent, or other IP claims have been asserted.
    Multiple independent vendors are developing ACAP clients and
    servers, in addition to the existing usage in deployed products.

6.  Handset Protocol Suites

6.1.  ACAP over TCP/IP

    Figure 5 depicts the mobile station protocol suite for the ACAP over
    TCP/IP solution.  The mobile station is capable of supporting both
    IS-683A OTASP and OTASP over ACAP.

                    [Figure 5 -- see PostScript version]



Gellens                      Informational                     [Page 23]

RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


7.  IS-683A Compatibility

7.1.  OTASP Operations

    To maximize compatibility and allow for reuse of IS-683A handset
    code, the data formats used in OTASP over ACAP are identical to
    those used in IS-683A.  Section 5.1.5  Data Organization and
    Capabilities discusses this in more detail.

    OTASP via IS-683A requires custom design and development for the
    specific CDMA infrastructure used by a carrier.  This can greatly
    limit the data management capabilities and significantly reduces the
    extensibility of the solution.  Conversely, OTASP over data can be
    implemented on a generic IP network using an Internet standards-
    based capability that provides extensible provisioning activities
    for carriers.

    OTASP over data uses a traffic channel whereas IS-683A OTASP runs
    over the limited-bandwidth signaling channel.

    IS-683A OTASP operations are inherently simultaneous voice and data.
    This allows the customer care representative to extract information
    from the mobile station while conversing with the user.  OTASP over
    data services is a data-only solution (at least for now).  This
    makes OTASP operations slightly more sequential and potentially
    problematic.  Simultaneous voice and data will alleviate this issue.

7.2   OTASP Call Flow

    The call flow diagram (Figure 6) depicts the message sequence and
    operations for a typical IS-683A OTASP (provisioning) call.  Any
    data-OTASP solution must perform all the functions of the IS-683A
    OTASP call.  The proposed solution meets these requirements.

                    [Figure 6 -- see PostScript version]

7.3.  OTAPA Operations

    Data-OTAPA requires the ability to instruct mobiles to originate a
    data call to the provisioning server.  Several viable approaches are
    discussed in sections 3.3  OTAPA Activity and 4.3  OTAPA
    Requirements.

    OTAPA over data has the potential to require far less channel
    resources to download new information to mobile stations.  The ACAP
    server inherently only communicates changes to the clients, thus
    only changed information needs to be downloaded to the mobile
    stations using OTAPA over data via ACAP.



Gellens                      Informational                     [Page 24]

RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


7.4.  OTAPA Call Flow

    The call flow diagram (Figure 7) depicts the message sequence for a
    typical IS-683A OTAPA operation.  Any data-OTAPA solution must
    perform all the functions of the IS-683A OTAPA call.  The proposed
    solution meets these requirements.

                    [Figure 7 -- see PostScript version]

8.  Alternative Methods

8.1.  IS-683A over TCP/IP

    One alternative is to port IS-683A to TCP, remaining as close as
    possible to the IS-683A protocol exchange.

    Figure 8 depicts the architecture and communications backbone to
    support OTASP/OTAPA via IS-707 data services with a provisioning
    server based on the IS-683A OTAF function.

                    [Figure 8 -- see PostScript version]

8.1.1.  OTAF Server

    This provisioning server is modeled after the IS-683A OTAF.  The
    OTAF server performs the specific operations and messaging of IS-
    683A OTAF.  This includes A-key reauthentication procedures.

    Strongpoints:

    (1) OTAF and mobile station behavior mirrors IS-683A (reduced
    duplicate software in mobile station).  Nearly all procedures fully
    defined.

    Drawbacks:

    (1) The OTAF server would need to be custom-designed and built.

    (2) No inherent data manipulation capabilities in the OTAF server.
    All required or desired data management activities would have to be
    built from scratch.

    (3) Interface application would require a non-standard interface
    (and therefore proprietary) to OTAF server.

    (4) End-to-end encryption scheme still needed for full security.





Gellens                      Informational                     [Page 25]

RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


8.1.2.  Interface Application

    This function loads all required provisioning-related information
    from the CDMA network information system to the OTAF server.  This
    includes the queuing of provisioning transactions and data.


8.1.3.  Protocol Handset Suite

    Figure 9 depicts the mobile station protocol suite for the IS-683A
    over TCP/IP solution.  The OTASP client is capable of supporting
    both IS-683A OTASP activities or OTASP activities over the data
    transport.

                    [Figure 9 -- see PostScript version]

8.2.  Browser-Based Forms

    Another alternative is to use forms embedded in web pages.

    Encapsulating the provisioning data into custom tags embedded in a
    web form is an idea that at first seems attractive.  There are a lot
    of advantages in having a browser in the handset, web servers are
    very widely deployed, and everyone is familiar on some level with
    the web.

    However, a meta-protocol for this would need to be designed, and a
    fully detailed specification produced.  This solution requires
    custom software on the provider side to handle the meta-protocol.
    It additionally requires handset vendors to add custom software in
    the handset browser to handle this protocol.

    This solution would require a provisioning-capable browser in every
    phone.  While it may be desirable to have a browser, the decision to
    require it needs to be considered carefully, especially in light of
    the memory requirements it would impose on all devices.

    This solution would complicate the handset browser, by requiring it
    to handle provisioning as well as browsing.  As provisioning and
    browsing are functionally dissimilar, this code is not a natural fit
    within the browser.  Implementing this solution would require a
    significant increase in development and debug resources, and thus
    negatively impact time-to-market and cost.

    Also because the web is functionally dissimilar, a high level of
    carrier-side customization would be needed, leading to reduced
    vendor choice and increased deployment costs.




Gellens                      Informational                     [Page 26]

RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


    This approach would layer custom data on top of a standard protocol.
    This would require design work, and would not have much time for
    open review before deployment, greatly increasing the risk.  By
    contrast, ACAP has had years of open review and refinement.

    This approach also limits the extensibility of the solution.  ACAP,
    conversely, is very extensible.  Because ACAP is such a simple
    protocol, it can be added to a wide variety of applications at low
    cost.  This allows increasing numbers of applications on the mobile
    device to share information with servers as well as desktop
    applications.

9.  Conclusion

    ACAP provides a high degree of extensibility, especially in
    authentication mechanisms, custom attribute handling, and data
    management.  By using an Internet standard protocol,
    interoperability and integration with a variety of equipment is
    possible, and carriers are not locked into any vendor.  It is also
    easier to add new levels of service and capabilities, especially
    integration with future subscriber devices and applications (e.g.,
    email).

    Since an ACAP client is so small, it can be incorporated into
    virtually any device, even low-end ones without displays, and can be
    added without sacrificing other features.  The simplicity of the
    client and protocol directly translate to shorter development cycles
    and faster time-to-market.

    Because the ACAP protocol was designed for precisely this type of
    provisioning activity, its adoption can greatly reduce the cost,
    time to market, and support required for the provisioning server as
    well as the handsets.  As an open standard, the ACAP protocol has
    benefited from years of review and experience.

    Another advantage of the ACAP solution is that is can easily coexist
    with a WAP-based mechanism, giving carriers more options and
    reducing the minimal requirement burden on mobile devices.

    A carrier can deploy handsets into its service area which use WAP-
    based provisioning, if desired, alongside those which use ACAP
    provisioning.  By using an ACAP server for provisioning, carriers
    are free to simultaneously deploy mobile stations that use either
    WAP or ACAP, as desired.

    The lack of intellectual-property issues further adds to ACAP's
    appeal.




Gellens                      Informational                     [Page 27]

RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


10.  References

    [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration
    Access Protocol", RFC 2244, November 1997.

    [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
    AUTHorize Extension for Simple Challenge/Response", RFC 2195,
    September 1997.

    [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
    RFC 2222, October 1997.

11.  Security Considerations

    Security is discussed in many sections of this document.  In
    particular, the need and methods to guard against unauthorized
    updating of handsets, usurpation of newly-created accounts,
    compromise of handset security values, and disclosure of carrier
    proprietary data and handset parameters is covered.

12.  Acknowledgments

    Jim Willkie and Marc Phillips contributed greatly to this document.
    Their help is very much appreciated.

13.  Author's Address

   Randall Gellens
   QUALCOMM Incorporated
   6455 Lusk Boulevard
   San Diego, CA  92121-2779

   Phone: [phone]
   EMail: [e-mail]

















Gellens                      Informational                     [Page 28]

RFC 2604                  OTASP/OTAPA via ACAP                 June 1999


14. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, publi