DOCSLIB.ORG

Certificate Discovery for Direct Project Implementation Guide V4.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Certificate Discovery for Direct Project Implementation Guide V4.1 Certificate Discovery for Direct Project Implementation Guide Version 4.1, 20 August 2015 Revision History Date Document Version Document Revision Description Revision Owner 2011-10-19 1.1 Revisions from F2F meeting Ken Pool 2011-10-24 2.0 Revisions from Bob Dieterle Bob Dieterle 2011-11-09 3.0 Revisions from Ken Pool Ken Pool 2011-12-14 4.0 First revision following comments Ken Pool 2015-08-20 4.1 Revision addressing corrections and clarifications identified by the Direct Certificate Discovery Tool (DCDT) team. Original Authors Workgroup Lead Ken Pool, OZ Systems Workgroup Lead Sri Koka, Techsant Technologies Participating Author Peter Bachman, Cequs Inc. Participating Author Bob Dieterle, EnableCare Participating Author Ernest Grove, SHAPE HITECH, LLC Participating Author Lester Keepper, SHAPE HITECH, LLC 1. Introduction The Provider Directories Initiative focuses on identifying the requirements, core data set, and standards to support two specific use cases: Discovery of Digital Certificates for the Direct Project; and Discovery of Electronic Service Information (including electronic address and any required security information) in order to support the electronic exchange of health information. The health care industry has utilized provider directories for years. The content of individual directories has varied substantially based upon intended use and audience. The Provider Directories Initiative created within the S&I Framework is not intended to replace existing directories - its primary goal is to support the electronic exchange of health information in a secure fashion. This Implementation Guide addresses the use case for discovery of digital certificates for the Direct Project using a hybrid approach based on DNS and LDAP. The Direct Project DNS Configuration Guide addresses the discovery of digital certificates stored in DNS CERT records. The hybrid approach to discovery of digital certificates extends the work described in that document to enable the universal discovery of certificates via LDAP services. Briefly, this guide’s approach for Direct Project certificate is: DNS is used as the entry point leveraging its global discoverability. LDAP is used when the DNS record does not support the CERT record or when LDAP is preferred by the publisher. See Section 3.1 for a detailed description. This guide provides specific technical guidance on: Publishing and discovering LDAP services using the DNS SRV record. Querying an LDAP service for digital certificate discovery using anonymous binding for a specific Direct Project address. The digital certificate(s) obtained from the query facilitate the secure exchange of health information. 1.1 Purpose This Implementation Guide enables providers and others to electronically obtain the digital certificate of a desired destination to support secure transfer of health information. Adopting and implementing this guide’s approach to certificate discovery provides the following benefits: The ability for providers and other authorized entities to retrieve digital certificate(s) to facilitate secure exchange of health information A standardized query mechanism for Certificate Directories that can be adopted by EHR and HIE vendors, State HIEs, HISPs and other mediators of exchange The standardization and simplification of the implementation of interfaces to query Certificate Directories 1.2 Scope The scope of this guide addresses a single scenario - in it, the digital certificate requester has a Direct Address associated with the digital certificate(s) being requested and queries a Certificate Directory to retrieve the digital certificate(s): Scenario 1: The digital certificate requester or the digital certificate requester system has a known Direct Address associated with the digital certificate being requested. The digital certificate requester’s system does not have the digital certificate(s) associated with the Direct Address. The digital certificate requester system sends a query to the Certificate Directory without user intervention. The Certificate Directory returns zero or more digital certificate(s) associated with the Direct Address. The digital certificate requester performs Certificate Validation on the digital certificate returned by the Certificate Directory. The digital certificate requester selects the correct digital certificate(s) for the intended use when multiple certificates are returned. 1.3 Audience This Implementation Guide is intended to assist providers, payers, and any other health care organization that wants to participate in secure health information exchange. Specifically it informs: Vendors/Developers, who need to understand, design, and develop Direct project compliant messaging. HISPS/Providers who are configuring DNS and LDAP services to support Direct certificate discovery. Registration Authorities/Certificate Authorities who certify health care organizations and/or individuals and issue Direct digital certificates. 1.4 Assumptions The Certificate Discovery for Direct Project Implementation Guide assumes the following: The certificate recipient will validate the certificate but this is not covered in this guide. Access to digital certificates for the Direct Project is assumed to be world readable. The Provider, Patient, and health care organizations and individuals who implement the Use Case will use the guide to enable interoperable exchange of protected health information (PHI) using Direct Project messaging. The Implementation Guide continues the methodology for defining needs, selecting and developing standards, and implementing those standards in a testable, sustainable way via the “Standards and Interoperability Framework – Use Case Development and Functional Requirements for Interoperability." The reader is familiar with the Direct Project. The Direct address is the canonical address. 2 Development of Guidance The Certificate Discovery for Direct Project Implementation Guide provides specific guidance for the development, implementation, and ongoing discovery of S/MIME digital certificates for known Direct defined addresses. To develop this guidance, the S&I Framework PD sprint team investigated currently available options for an open and universally accessible approach to discovering S/MIME digital certificates using only the Direct address. The investigation focused on two specific, highly deployed technologies – DNS and LDAP. The hybrid approach to discovery of digital certificates is based on the findings of this investigation. This hybrid approach ensures: That the digital certificate can be obtained if located in a DNS CERT record That the digital certificate can be obtained if located in an LDAP implementation That existing DNS implementations that do not support CERT can facilitate locating the digital certificate That data contained in LDAP implementations by health care organizations that store S/MIME certificates can contribute to this use case. A complete summary of the team’s findings can be found in Appendix D: Development of Guidance. 3 Implementation Guide As defined by Direct project, a “Security Trust Agent (STA)” refers to the actor who has a Direct address to which they wish to send information and for which they need to obtain the associated digital certificate. In general, we expect the STA to actually be an application or a service used by the sender. The “Publisher” refers to the actor who has digital certificates for specific Direct addresses and wishes to make those digital certificates available for use. We also will refer to the organization Direct address DNS record as the full domain specification consistent with the Direct Project Rules of the Road communities. We assume that both the consumer application and the publisher are familiar with the basics of DNS and LDAP. We also assume they both adhere to industry best practices in their use of these technologies. Lastly, we assume the reader is familiar with the Direct Project Rules of the Road and especially the Direct Project – Applicability Statement for Secure Health Transport. Briefly, this guide’s approach for Direct Project certificate discovery is: ● DNS is used as the entry point leveraging its global discoverability. ● LDAP is used when the DNS record does not support the CERT record or is preferred by the publisher. See Section 3.1 for a detailed description. DNS allows for multiple Resource Records (RR) that support the storage of a number of different content types. This guide uses RR capability in two ways. First, a digital certificate can be stored in a CERT RR if the CERT RR has been entered into a DNS zone record. Second, the domain name and port information for an LDAP service can be stored in a SRV RR as defined by RFC-2782, “A DNS RR for specifying the location of services (DNS SRV)”. The SRV RR standard also allows for multiple LDAP service instances to be advertised with a standard protocol for establishing the relative priority among them. For this guide, the STA is expected to establish their criteria for what they consider a valid digital certificate for their use. For guidance on validating certificates for use in Direct, see the policies as detailed in Direct Project – Applicability Statement for Secure Health Transport Section 4.0 and Direct Communities of interest for specific stakeholders. While security surrounding the proper use of digital certificates is beyond the scope of this initiative the STA may wish to consider whether the DNS resolver implements DNSSEC to protect against security flaws. 3.1 DNS/LDAP Hybrid Digital Certificate
Load more

Recommended publications
  • Dnsservicediscovery Mach-Based API
    DNSServiceDiscovery Mach-Based API February 1, 2004 REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS MANUAL, Apple Computer, Inc. ITS QUALITY, ACCURACY, © 2001, 2004 Apple Computer, Inc. MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS All rights reserved. MANUAL IS SOLD ªAS IS,º AND YOU, THE PURCHASER, ARE ASSUMING THE ENTIRE No part of this publication may be RISK AS TO ITS QUALITY AND ACCURACY. reproduced, stored in a retrieval system, or IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, transmitted, in any form or by any means, OR CONSEQUENTIAL DAMAGES mechanical, electronic, photocopying, RESULTING FROM ANY DEFECT OR INACCURACY IN THIS MANUAL, even if recording, or otherwise, without prior advised of the possibility of such damages. written permission of Apple Computer, Inc., THE WARRANTY AND REMEDIES SET with the following exceptions: Any person FORTH ABOVE ARE EXCLUSIVE AND IN is hereby authorized to store documentation LIEU OF ALL OTHERS, ORAL OR WRITTEN, EXPRESS OR IMPLIED. No Apple dealer, agent, on a single computer for personal use only or employee is authorized to make any and to print copies of documentation for modification, extension, or addition to this warranty. personal use provided that the Some states do not allow the exclusion or documentation contains Apple’s copyright limitation of implied warranties or liability for notice. incidental or consequential damages, so the above limitation or exclusion may not apply to The Apple logo is a trademark of Apple you. This warranty gives you specific legal Computer, Inc. rights, and you may also have other rights which vary from state to state.
    [Show full text]
  • Polycom UC Software 5.4.3 Administrator Guide
    ADMINISTRATOR GUIDE UC Software 5.4.3 | March 2016 | 3725-49104-010A Polycom® UC Software 5.4.3 Copyright© 2016, Polycom, Inc. All rights reserved. No part of this document may be reproduced, translated into another language or format, or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc. 6001 America Center Drive San Jose, CA 95002 USA Trademarks Polycom®, the Polycom logo and the names and marks associated with Polycom products are trademarks and/or service marks of Polycom, Inc. and are registered and/or common law marks in the United States and various other countries. All other trademarks are property of their respective owners. No portion hereof may be reproduced or transmitted in any form or by any means, for any purpose other than the recipient's personal use, without the express written permission of Polycom. Disclaimer While Polycom uses reasonable efforts to include accurate and up-to-date information in this document, Polycom makes no warranties or representations as to its accuracy. Polycom assumes no liability or responsibility for any typographical or other errors or omissions in the content of this document. Limitation of Liability Polycom and/or its respective suppliers make no representations about the suitability of the information contained in this document for any purpose. Information is provided "as is" without warranty of any kind and is subject to change without notice. The entire risk arising out of its use remains with the recipient. In no event shall Polycom and/or its respective suppliers be liable for any direct, consequential, incidental, special, punitive or other damages whatsoever (including without limitation, damages for loss of business profits, business interruption, or loss of business information), even if Polycom has been advised of the possibility of such damages.
    [Show full text]
  • Page 1 of 65 Chapter 6
    Chapter 6 - Windows 2000 DNS Page 1 of 65 Windows 2000 Server Chapter 6 - Windows 2000 DNS Microsoft® Windows® 2000 DNS is compliant with the standard Domain Name System (DNS) as described in the Request for Comments (RFC) documents of the Internet Engineering Task Force (IETF). DNS is the de facto naming system for Internet Protocol (IP)–based networks and the naming service that is used to locate computers on the Internet. Because Windows 2000 DNS is RFC- compliant, it interoperates with most of the other DNS server implementations, such as those DNS servers that use the Berkeley Internet Name Domain (BIND) software. This chapter describes the new features and enhancements of Windows 2000 DNS and explains how to set up and configure some of the features. For more information about DNS-related RFC standards that are supported by Windows 2000, see "Introduction to DNS" in this book. In This Chapter Introduction to the Windows 2000 Implementation of DNS Naming Hosts and Domains Windows 2000 Resolver Setting Up DNS for Active Directory Active Directory Integration and Multimaster Replication Dynamic Update and Secure Dynamic Update Aging and Scavenging of Stale Records Integration with WINS Interoperability with Other DNS Servers Internet Access Considerations Troubleshooting Related Information in the Resource Kit l For more information about TCP/IP, see "Introduction to TCP/IP" in this book. l For more information about the Windows Internet Name Service, see "Windows Internet Name Service" in this book. l For information about Domain Name System concepts, see "Introduction to DNS" in this book. l For more information about Active Directory, see "Active Directory Logical Structure" in Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide.
    [Show full text]
  • Networks: Access Management Windows 2000 Server Class Notes # 18 Domain Name Server (Part I) February 12, 2004
    Networks: Access Management Windows 2000 Server Class Notes # 18 Domain Name Server (Part I) February 12, 2004 Computers connected to a network require distinct IP addresses in order to communicate using the TCP/IP protocol. The IP addresses provide a distinct location for the sending and receiving of information. The IP addresses consist of a complicated set of numbers (4 octet address) that is not easy to remember. Therefore, DNS is used to provide a mapping between a name and its IP address. DNS is made up of many elements to provide name resolution for clients on a TCP/IP network, including name servers, domains, zones, zone files, and records. For any computer on the Internet, you can find the address of any other computer using the DNS hierarchy or namespace. This information is acquired within seconds. There is no one person or organization keeping track of the DNS machine name to IP address database. The responsibility for keeping track of the name to IP address relationship is maintained locally. For example, if your DNS server tries to figure out the IP address of www.google.com then your DNS server is soon going to be talking to the google DNS server to resolve that name. The DNS names are arranged in pieces separated by a period. For example, teacher.wqsb.qc.ca has four pieces where each piece can’t exceed 63 characters in length and the entire name can’t exceed 255 characters in total. The left most piece is the computer name, the remaining pieces to the right of the computer name is the DNS domain or DNS suffix.
    [Show full text]
  • Interdomain Federation Guide for IM and Presence Service on Cisco Unified Communications Manager, Release 11.5(1)SU2 First Published: 2017-01-10
    Interdomain Federation Guide for IM and Presence Service on Cisco Unified Communications Manager, Release 11.5(1)SU2 First Published: 2017-01-10 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 © 2017 Cisco Systems, Inc. All rights reserved. CONTENTS CHAPTER 1 Overview of this Integration 1 Basic Federated Network 1 SIP Federation with AOL 4 Limitation with AOL Federation 4 Intercluster and Multinode Deployments 5 SIP Federation Deployments 5 XMPP Federation Deployments 5 High Availability and Federation 6 High Availability for SIP Federation 6 High Availability for XMPP Federation 7 Cisco Adaptive Security Appliance Deployment Options 9 Presence Subscriptions and Blocking Levels 10 Availability State Mappings 12 Availability State Mappings for Microsoft OCS 12 Availability State Mappings for Microsoft Lync 14 Availability State Mappings for AOL Instant Messenger 15 Availability State Mappings for XMPP Federation 16 Instant Messaging 18 Instant Message Flow for SIP Federation 18 Availability and Instant Message Flow for XMPP Federation 20 Federation in Deployments with Multiple Domains 21 Federation and Subdomains 21 CHAPTER 2 Preparations for this Integration 23 Supported Interdomain Federation Integrations 23 Presence Web Service API Support 24 Hardware Requirements 24 Software Requirements 25 Interdomain Federation Guide for IM and Presence Service on Cisco Unified Communications Manager, Release 11.5(1)SU2 iii Contents
    [Show full text]
  • Active Directory DNS Integration.Book
    Active Directory DNS Integration White Paper Abstract This paper describes how Active Directory uses the Domain Name System (DNS) in conjunction with the Windows Domain Locator service for distributed computing environments. It discusses how the Adonis Server integrates into existing or new Active Directory deployments. DNS replication mechanisms are discussed including their pros and cons. Active Directory records and DNS labeling conventions are described in detail to give the reader a deeper understanding how the locator service works. USE OF THIS DOCUMENT Publisher Information All rights reserved worldwide. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language in any form or by any means without the express written permission of: BlueCat Networks, Inc. 9050 Yonge Street, Suite 401 Richmond Hill, Ontario Canada L4C 9S6 Attention: General Manager Telephone: 905-882-5691 Fax: 905-882-5057 E-mail: [email protected] Web Site: www.bluecatnetworks.com This publication is provided as is without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. All terms mentioned in this publication that are known to be trademarks or service marks are appropriately capitalized. BlueCat Networks cannot attest to the accuracy of this information. Use of a term in this publication should not be regarded as affecting the validity of any trademark or service mark. The trademarks, service marks and logos (the "Trademarks") displayed are registered and unregistered Trademarks of BlueCat Networks, Inc. and others.
    [Show full text]
  • Kerio-Connect-Adminguide.Pdf
    ADMINISTRATOR GUIDE Find out how to install and configure Kerio Connect in different environments and how to set up advanced features. The information and content in this document is provided for informational purposes only and is provided "as is" with no warranties of any kind, either express or implied, including without limitation any warranties of merchantability, fitness for a particular purpose, and non-infringement. GFI Software disclaims and in no event shall be liable for any losses or damages of any kind, including any consequential or incidental damages in connection with the furnishing, performance or use of this document. The information is obtained from publicly available sources. Though reasonable effort has been made to ensure the accuracy of the data provided, GFI makes no warranty, promise or guarantee about the completeness, accuracy, recency or adequacy of information contained in this document and is not responsible for misprints, out-of-date information, or errors. GFI reserves the right to revise or update its products, software or documentation without notice. You must take full responsibility for your use and application of any GFI product or service. No part of this documentation may be reproduced in any form by any means without prior written authorization of GFI Software. If you believe there are any factual errors in this document, please contact us and we will review your concerns as soon as practical. GFI and Kerio Connect are trademarks or registered trademarks of GFI Software or its affiliates in the US and other countries. Any other trademarks contained herein are the property of their respective owners.
    [Show full text]
  • Icewarp Server GUI Reference
    IceWarp Unified Communications IceWarp Server GUI Reference Version 11.4 Published on 5/3/2016 Contents Reference Manual ..................................................................................... 5 Administrative Console ................................................................................................................... 6 Main Menu ........................................................................................................................ 7 Remote Server Administration ........................................................................................ 10 Remote Console as an Installer ........................................................................... 10 Bookmarks – Bookmarks Manager ...................................................................... 11 Configuration Backup and Restore .................................................................................. 14 Toolbar ............................................................................................................................. 15 How to Import Users from Windows or AD Servers ........................................................ 16 How to Import Users from LDAP / Active Directory ......................................................... 17 Import/Export Users from/to File .................................................................................... 18 Licenses ............................................................................................................................ 20 WebAdmin ......................................................................................................................
    [Show full text]
  • Professional Manual
    Professional Manual 1 Table of Contents 1. Table of Contents 1-8 2. Introduction 9 2.1. Introduction 9 2.2. Prerequisites 9-10 2.3. How Internet Email Works 10-11 2.4. What's New in Version 10 11-12 3. Overview 13 3.1. Overview 13 3.2. Structure of MailEnable 13-14 3.3. Administration 14-15 3.4. Email Delivery Flow 15-16 4. Installation 17 4.1. Installation Overview 17 4.2. Installation process 17-25 4.3. Upgrading 25 4.3.1. Upgrading Overview 25 4.3.2. Upgrading an existing web mail installation 25-26 4.3.3. Configuration repository location 26 4.3.4. Replace configuration files 26-27 4.4. Post-installation configuration 27 4.4.1. MailEnable Diagnostic Utility 27-29 4.4.2. Check and configure DNS settings 29 4.4.3. To set up PTR records under Microsoft's DNS Server 29-30 4.4.4. Check mail services 30 5. Administration 31 5.1. Administration Overview 31 5.2. Messaging Manager 31 5.2.1. Messaging Manager Overview 31-32 5.2.2. Messaging Manager - General 32 5.2.3. Messaging Manager - Administration 32-33 5.2.4. Messaging Manager - Security 33-34 1 ©2018 MailEnable Pty Ltd. All Rights Reserved. Professional Manual 5.2.5. Messaging Manager - Footers 34 5.3. Post office configuration 34 5.3.1. Post office configuration Overview 34-35 5.3.2. How to create a Post Office 35 5.3.3. Post office - General 35-36 5.3.4.
    [Show full text]
  • (IETF) C. Daboo Request for Comments: 6764 Apple Inc. Updates: 4791, 6352 February 2013 Category: Standards Track ISSN: 2070-1721
    Internet Engineering Task Force (IETF) C. Daboo Request for Comments: 6764 Apple Inc. Updates: 4791, 6352 February 2013 Category: Standards Track ISSN: 2070-1721 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) Abstract This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6764. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
    [Show full text]
  • DNS Servers Are Used to Resolve FQDN Hostnames Into IP Addresses and Vice Versa
    >What is the main purpose of a DNS server? DNS servers are used to resolve FQDN hostnames into IP addresses and vice versa. >What is the port no of dns ? 53. >What is a Forward Lookup? Resolving Host Names to IP Addresses. >What is Reverse Lookup? It?s a file contains host names to IP mapping information. >What is a Resource Record? It is a record provides the information about the resources available in the N/W infrastructure. >What are the diff. DNS Roles? Standard Primary, Standard Secondary, & AD Integrated. >What is a Zone? Zone is a sub tree of DNS database. >Secure services in your network require reverse name resolution to make it more difficult to launch successful attacks against the services. To set this up, you configure a reverse lookup zone and proceed to add records. Which record types do you need to create? PTR Records >SOA records must be included in every zone. What are they used for ? SOA records contain a TTL value, used by default in all resource records in the zone. SOA records contain the e-mail address of the person who is responsible for maintaining the zone. SOA records contain the current serial number of the zone, which is used in zone transfers. >By default, if the name is not found in the cache or local hosts file, what is the first step the client takes to resolve the FQDN name into an IP address ? Performs a recursive search through the primary DNS server based on the network interface configuration . > What is primary, Secondary, stub & AD Integrated Zone? Primary Zone: - zone which is saved as normal text file with filename (.dns) in DBS folder.
    [Show full text]
  • [MS-OXDISCO]: Autodiscover HTTP Service Protocol Specification
    [MS-OXDISCO]: Autodiscover HTTP Service Protocol Specification Intellectual Property Rights Notice for Protocol Documentation Copyrights. This protocol documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the protocols, and may distribute portions of it in your implementations of the protocols or your documentation as necessary to properly document the implementation. This permission also applies to any documents that are referenced in the protocol documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that may cover your implementations of the protocols. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, the protocols may be covered by Microsoft’s Open Specification Promise (available here: http://www.microsoft.com/interop/osp). If you would prefer a written license, or if the protocols are not covered by the OSP, patent licenses are available by contacting [email protected]. Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise. Tools. This protocol documentation is intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it.
    [Show full text]