We’re excited that you’ve chosen to develop applications that help Medicare beneficiaries by improving their access to their BlueButton health data. We created this platform to enable you to connect beneficiaries' information to applications that put their health data to use for their health and the health of those they care about..
Note: You are agreeing to abide by a Code of Honor that is intended to protect Beneficiaries and their data.
Last revised on January 30, 2015.
You agree that by using the CMS BlueButton Platform (“Platform”), you are entering into a legally binding agreement with Centers for Medicare & Medicaid Services 7500 Security Boulevard, Baltimore, MD 21244, USA (“we,” “us,” “our,” and “CMS”). By registering for an account (a “Developer Account”) at the CMS BlueButton Developer Network site at developer.cms.gov (the “Developer Site”), you acknowledge that you have read and understood and agree to be bound by this CMS BlueButton API Developer Code (the “Terms”). If you are using our Developer Platform on behalf of a company or other entity, you represent and warrant that you have full legal authority to register for a Developer Account on behalf of that entity and bind it to these Terms. If you are not authorized, you may not accept the Terms or register for a Developer Account for someone else.
These Terms will evolve, so please check back regularly. It is your responsibility to remain informed of these Terms.
A. Purpose
B. The mission of CMS is to strengthen and modernize the nation’s health care system to provide access to high quality care and improved health at lower cost. To achieve our mission, we make APIs available to third party developers such as you to create applications for our beneficiaries and business partners.
C. Scope and Intent
D. The CMS BlueButton Developer Program includes a self-service platform program, where you can develop applications using CMS APIs as soon as you register for a Developer Account and agree to follow these Terms and meet our Platform Program eligibility criteria and you have entered into a signed Data Use agreement with CMS.
E. As used in these Terms, “APIs” means programmatic web APIs and associated tools and documentation that CMS provides, and “Application” means a software application, website, or product you create or a service you offer.
F. Here are the guidelines to determine which of CMS’ developer programs fits your Application:
1. Self-Service Program
2. You may use our self-service program if you are developing an Application designed to help CMS Beneficiaries gain access to and make improved use of their personal health information; for example, by consolidating their health data from CMS and other sources to create a consolidated health timeline.
3. You cannot use our self-service program and must talk to us directly, as you may be subject to additional Terms, if your Application:
● is expected to:
○ have more than 50,000 lifetime members; or
○ make more than 10,000 daily calls to a CMS BlueButton API; or
● relies on access to CMS APIs as a fundamental aspect of your business.
● will store or export any data from CMS other than a beneficiaries’ personal health data (name, contact information, health history, claims history) and share that information with other applications and services without the express permission of the beneficiary.
4. Partner Program
5. You must apply to our Platform Partner Program and cannot use our self-service program if your Application aggregates beneficiary personal data and re-sells that information whether or not the data is anonymized.
6. For more information about the Platform Partner Program application process, eligibility criteria and the areas where we are looking for partners visit BlueButton Partner Programs.
A. Developer Accounts and Access Credentials
1. Developer Account
2. To use our self-service APIs, you must first sign up for a Developer Account. The Developer Account must contain accurate and up-to-date information at all times, including your current title, company, and e-mail address. You agree that we can use, store, and share information submitted by you through your Developer Account as permitted in our Privacy Policy.
3. Access Credentials
4. Once you have a Developer Account you may obtain Access Credentials for your Application. “Access Credentials” means the necessary security keys, secrets, tokens, passwords, and other credentials to access the APIs. The Access Credentials enable us to associate your API activity with your Application and the beneficiaries using it. All activities that occur using your Access Credentials are your responsibility. Keep them secret. Do not sell, transfer, or sublicense them. Do not try to circumvent them. And do not require your users to obtain their own Access Credentials to use your Application.
5. Test Account
6. You will be given access to CMS test accounts for testing purposes only.
7. API License
8. As long as you follow these Terms, we grant you a limited, non-exclusive, non-assignable, non-transferable license to use the APIs to develop, test, and support your Application, and to let your customers use your integration of the APIs within your Application.
A. Display and Use Content Properly
●
Data Views
●
Beneficiary’s view of their CMS BlueButton data are private to
them. Each user must give you express permission to access their CMS BlueButton
data through your Application, and you must provide the user’s account only to
that user and no one else. In addition, your Application must obtain the
express permission of the user before sharing their BlueButton information with
anyone else.
●
Excluded Uses
●
You must never do any of the following under these Terms:
a. Use the APIs in any Application that includes adult content, promotes gambling, involves the sale of tobacco or alcohol to persons under 21 years of age, or otherwise violates any law or regulation.
b. Sell, lease, share, transfer, or sublicense any BlueButton-derived content or access to any BlueButton-derived Content, directly or indirectly, to anybody without the express consent from the beneficiary that has downloaded, uploaded or imported CMS BlueButton data into your application. That includes data brokers, salespeople, advertisers, social or professional networks, or anyone besides yourself or the company on whose behalf you agreed to these Terms.
c. Use someone’s Access Credentials to show his or her Content to someone else, e.g., as part of search results. Each user must authenticate individually to retrieve his or her Content through the APIs.
d. Distribute or allow access to the stand-alone APIs to anyone other than the company on whose behalf you agreed to these Terms, or create an API that enables access to CMS BlueButton Content. Anyone who wants to access our APIs and Content must register for our Developer Program.
B. Store Content Only As Allowed
●
You May Store Tokens
●
You may store the alphanumeric user IDs (Member Tokens) that we
provide to you for identifying users or any individual member’s authentication
token (OAuth Token) that we provide to you when a CMS Beneficiary authenticates
your Application to their CMS account. The Member Token will be an anonymous
identifier.
●
Cache for Performance
●
To improve the member experience, you may cache the Content for
up to 24 hours from a request for that Content through the API. This limited
permission to cache is for performance reasons only. You do not have any rights
to store the CMS BlueButton Content beyond this limited 24-hour period.
●
Member Profile Data
●
You may store a beneficiary’s Profile Data if you have the
consent of the beneficiary to do so. “Profile Data” means the name and other
identifying information regarding the beneficiary. The process for obtaining
member consent must meet our specifications set forth at
{# TODO: create /accounts/info/obtain_consent_to_store_profile_data #}
Specifications for Obtaining Consent To Store Profile Data.
●
Protection of Stored
Data
●
You must use commercially reasonable security measures to
protect the confidentiality of all stored data, which measures are at least as
secure as those you use to protect your own confidential information. The
stored data must not be transferred or provided to any third parties. CMS may
require that you certify that you have deleted stored data.
C. Delete Content When Asked
●
Delete at User Request
●
You must delete all data collected with the user’s consent,
including the Member Token and the OAuth Token, upon request by the user, when
the user uninstalls your Application, or when the user closes his or her
account with you. The restrictions of this Section 3.C.1 do not apply to data
that users provide directly to you and that is separately entered or uploaded
to you by the user of your Application. You must delete all Profile and
Statistics Data based on the beneficiary’s BlueButton data collected with your
client's consent within 10 days of receiving a request from your client.
●
Delete for Breach
●
You must immediately delete all data if we terminate your use of
the APIs for breach of these Terms, except when doing so would cause you to
violate any law or obligation imposed by a governmental authority.
D. Don’t Harm or Trick Beneficiaries
●
Your Application must include your own user agreement and
privacy policy. Your user agreement and privacy policy must be prominently
identified or located where users download or access your Application. You must
promptly notify us of any breaches of your user agreement or privacy policy
that impact or may impact our beneficiaries. Your privacy policy must be at
least as stringent and user-friendly as CMS’.
●
Before obtaining information from your users of the Application,
you must obtain their informed consent by informing them what information you
collect and how it will be used and/or shared.
●
Your Application must not:
a. Implement features or business practices that harm Beneficiaries.
b. Impersonate a beneficiary or misrepresent any user or other third party when requesting or publishing information.
c. Obfuscate or hide any CMS buttons, sign-in functionality, consent, or authorization flows from your users. In order to access beneficiary-specific Content through the APIs, your users must sign-in with their CMS credentials and grant your Application access to their Content.
d. Proxy, request, or use CMS usernames or passwords in any fashion for any reason. We want our beneficiaries to have safe and consistent experiences across all Applications.
E. Be a Good Citizen to our Platform
●
When you use the CMS BlueButton APIs, you share the access with
beneficiaries and other applications that they trust and fellow developers.
Write your Application as you’d want others to write theirs.
a. Only ask for the minimum data fields your Application needs.
b. Don’t try to exceed or circumvent your limitations on calls and use. This includes creating multiple Applications for identical, or largely similar, usage (e.g., having one Application per customer). If we believe that you have exceeded or circumvented our limitations, or if you have tried to, we may temporarily suspend or permanently block your access to the APIs, disable your developer account, or both.
c. Don’t download, scrape, post, or transmit, in any form or by any means, any part of our Website. This includes data retrieved by web browser plugins.
d. Don’t copy, reformat, reverse-engineer, or otherwise modify the APIs, Access Credentials, our Website or any Content.
e. Don’t interfere with or disrupt CMS services or servers or networks connected to CMS services, or disobey any requirements, procedures, policies or regulations of networks connected to CMS services.
F. Treat the CMS name With Respect
●
Brand Features License
●
Subject to these Terms, including the
{# TODO: create /accounts/info/branding_guidelines #}
BlueButton Branding Guidelines, we grant you a limited, non-exclusive, non-assignable,
non-sublicenseable, and non-transferable license during the Term to promote or
advertise your integration of the CMS BlueButton APIs in your Application.
●
Restrictions.
●
You must not:
a. Display the CMS name or logo in any way that is misleading, defamatory, infringing, libelous, disparaging, obscene, or otherwise objectionable to CMS in its sole discretion, or in a way that suggests we have created, sponsored, or endorsed your Application or its content;
b. Remove any legal, copyright, trademark, watermark or other proprietary rights notices contained in or on materials you receive or access pursuant to these Terms, including the APIs, the materials posted at the Developer Site, and our Website; or
c. Use the APIs or CMS name for any illegal, unauthorized or otherwise improper purposes, or in any manner that would violate these Terms (or any document incorporated into the Terms), or breach any laws or regulations, or violate any rights of third parties, or expose CMS or its beneficiaries to legal liability in your use of the APIs.
●
Publicity by You
●
Subject to our Branding Guidelines, you may promote your
Application, including talking to traditional and online media and your users
about your Application, so long as you do so truthfully and without implying that
your Application is created or endorsed by CMS (or otherwise embellishing your
relationship with CMS). However, you may not issue any formal press release via
traditional or online media referring to CMS without CMS’ prior consent, unless
expressly allowed in the Branding Guidelines.
●
Publicity by Us
●
We may publicly refer to you, orally or in writing, as a
licensee of the CMS BlueButton APIs. We may also publish your name and logo
(with or without a link to your Application) on our Website, in press releases,
and in promotional materials without your prior consent.
G. Follow The Law and These Terms
H. You must comply with all applicable laws, including, the Digital Millennium Copyright Act and applicable export laws, and these Terms, which may be amended from time to time with or without advance notice, in order to use the CMS BlueButton APIs. You and your Application must also comply with the following, which are hereby incorporated by reference:
● {# TODO: create /accounts/info/user_agreement #} The CMS User Agreement;
● {# TODO: create /accounts/info/privacy_policy #} The CMS Privacy Policy;
● {# TODO: create /accounts/info/platform_guidelines #} The BlueButton Platform Guidelines, which are located at the Developer Site; and
● {# TODO: create /accounts/info/branding_guidelines #} The BlueButton Branding Guidelines.
I. In the event of any conflict between the content in this document and the above documents, this document controls your use of the APIs. If you disagree with any of the provisions in these Terms, do not access or use the APIs.
J. The most current version of these Terms can be reviewed on the Developer Site. By using the CMS BlueButton APIs after changes are made to the Terms, you agree to be bound by the most current version. If you disagree with the Terms, or changes to the Terms, you must discontinue your use of the APIs.
K. If we have entered into a separate, written API License Agreement with you, the terms of that agreement will govern your use of those APIs.
A. Security Measures
B. Your network, operating system and the software of your web servers, databases, and computer systems (collectively, “Systems”) must be properly configured to securely operate your Application. You must not architect or select Systems in a manner to avoid the foregoing obligation. You must promptly report any security deficiencies in or intrusions to your Systems that you discover to CMS in writing via email to<EMAIL_ADDRESS>or subsequent contact information posted in the Developer Site. You will work with CMS to immediately correct any security deficiency, and will disconnect immediately any intrusions or intruder. In the event of any security deficiency or intrusion involving the Application, you will make no public statements (e.g. press, blogs, social media, bulletin boards, etc.) without prior written and express permission from CMS in each instance.
C. Monitoring
D. You agree to assist CMS in verifying your compliance with these Terms by providing information about your Application to us, which may also include access to your Application and other materials related to your use of the APIs. If you do not demonstrate full compliance with these Terms, we may restrict or terminate your access to the APIs.
A. Support and Modifications
B. We may provide you with support or modifications for the APIs in our sole discretion. We may stop providing support or modifications to you at any time without notice or liability to you. We may release subsequent versions of the APIs and require that you use those subsequent versions. Your continued use of the APIs following a subsequent release will be deemed your acceptance of modifications.
C. Fees
D. The APIs are currently provided for free, but CMS reserves the right to charge for the APIs in the future. If we do charge a fee for use of the APIs or any developer tools and features, you do not have any obligation to continue to use CMS’s developer resources.
E. CMS Independent Development
F. You understand and acknowledge that CMS may be independently creating applications, content, and other products or services that may be similar to or competitive with your Application. Nothing in these Terms will be construed as restricting or preventing CMS from creating and fully exploiting any applications, content, and other items, without any obligation to you.
G. Developer Exception to our Privacy Policy
H. CMS may reveal personal information about developers for attribution purposes, handling inquiries from users or potential users, and other purposes CMS reasonably deems necessary under these Terms. You understand and agree that CMS may access, preserve, and disclose your personal information and your developer account details if required to do so by law or in a good faith belief that such access, preservation, or disclosure is reasonably necessary to comply with legal process or to protect the rights, property, or safety of CMS its affiliates or partners, its users, or the general public.
A. CMS Property
B. As between you and us, we own all rights, title, and interest, including all intellectual property rights, in and to, the (a) APIs, and all elements, components, and executables of the APIs; (b) the Content available through the APIs; (c) our Website; and (d) our Brand Features (clauses (a)-(d) collectively, the “CMS Materials”). Except for the express licenses granted in these Terms, CMS does not grant you any right, title, or interest in theCMS Materials. You agree to take such actions, including executing affidavits or other documents, as CMS may reasonably request to effect, perfect, or confirm CMS’ rights to the CMS Materials.
C. Your Property
1. Contributions to CMS
2. By submitting suggestions or other feedback regarding the CMS Materials ("Contributions") in any way to CMS, you acknowledge and agree that: (a) your Contributions do not contain confidential or proprietary information; (b) CMS is not under any obligation of confidentiality, express or implied, with respect to the Contributions; (c) CMS shall be entitled to use or disclose (or choose not to use or disclose) such Contributions for any purpose, in any way, in any media worldwide; (d) CMS may have something similar to the Contributions already under consideration or in development; (e) you irrevocably non-exclusively license to CMS rights to exploit your Contributions; and (f) you are not entitled to any compensation or reimbursement of any kind from CMS under any circumstances.
3. Your Application
4. You represent and warrant to CMS that, excluding CMS Materials, you have the right to use, reproduce, transmit, copy, publicly display, publicly perform, and distribute your Application, and that use by CMS and its users of your Application will not violate the rights of any third party (e.g., copyright, patent, trademark, or other proprietary right of any person or entity), or any applicable regulation or law, including the laws of any country in which your Application is made available. Except to the extent your Application contains CMS Materials, CMS claims no ownership or control over your Application. During the term of these Terms you hereby grant to us a paid-up, royalty-free, non-exclusive, worldwide, irrevocable right and license, under all of your intellectual property rights, to: (a) use, perform, and display your Application and its content for purposes of marketing, demonstrating, and making your Application available to users; (b) link to and direct users to your Application; and (c) sublicense the foregoing rights to our affiliates. Following the termination of these Terms and upon written request from you, CMS will make commercially reasonable efforts, as determined in its sole discretion, to remove all references and links to your Application from the Website and service. CMS has no other obligation to delete copies of, references to, or links to your Application.
A. Term
B. The term of these Terms will commence on the date upon which you agree to these Terms and will continue until: you discontinue using our APIs, you close your Developer Account, or we terminate your access to the APIs, these Terms, or both.
1. Suspension; Termination
2. We may suspend or terminate your use of all or any of the APIs at any time if we believe you have violated these Terms or, if we believe the availability of the APIs in your Application is not in our or our uers’ best interests. We may discontinue the availability of some or all of the APIs at any time for any reason. We may also impose limits on certain features and services or restrict your access to some or all of the APIs or our Website. All of our rights in these Terms may be exercised without prior notice or liability to you.
3. Effect of Termination
4. Upon termination of the agreement between you and us under these Terms:
a. all rights and licenses granted to you will terminate immediately;
b. you will promptly destroy CMS confidential information in your possession or control;
c. neither party is liable to the other party just because these Terms have been terminated; and
d. unless we agree otherwise in writing or as stated in these Terms, you must permanently delete all Content or other data which you stored pursuant to your use of the APIs.CMS may request that you certify in writing your compliance with this section.
5. Survival
6. The terms of this Agreement shall survive any termination, except Section 2 (“Joining our Self-Service Program”), subsections 2-5 of Section 3.B. (“Store Content Only as Allowed”), subsections 1, 2, and 4 of Section 3.F. (“Treat Our Brand With Respect”) and Section 4.A. (“Security Measures”).
SOME COUNTRIES AND JURISDICTIONS DO NOT ALLOW THE DISCLAIMER OF IMPLIED TERMS IN CONTRACTS WITH CONSUMERS AND AS A RESULT THE CONTENTS OF THIS SECTION MAY NOT APPLY TO YOU. DO NOT RELY ON CMS OR ITS SUPPLIERS, ANY INFORMATION THEREIN, OR ITS CONTINUATION.  WE DO NOT PROVIDE ANY EXPRESS WARRANTIES OR REPRESENTATIONS.  CMS DOES NOT GUARANTEE THAT THE CMS BLUEBUTTON APIS OR OTHER DEVELOPER RESOURCES IT PROVIDES WILL FUNCTION WITHOUT INTERRUPTION OR ERRORS IN FUNCTIONING. IN PARTICULAR, THE OPERATION OF THE CMS APIS MAY BE INTERRUPTED DUE TO MAINTENANCE, UPDATES, OR SYSTEM OR NETWORK FAILURES.  FURTHERMORE, CMS DISCLAIMS ALL LIABILITY FOR ANY MALFUNCTIONING, IMPOSSIBILITY OF ACCESS, OR POOR USE CONDITIONS OF THE CMS APIS DUE TO INAPPROPRIATE EQUIPMENT, DISTURBANCES RELATED TO INTERNET SERVICE PROVIDERS, TO THE SATURATION OF THE INTERNET NETWORK, AND FOR ANY OTHER REASON.
SOME COUNTRIES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY IN CONTRACTS WITH CONSUMERS AND AS A RESULT THE CONTENTS OF THIS SECTION MAY NOT APPLY TO YOU. Neither CMS nor any of our subsidiaries, affiliated companies, suppliers, employees, shareholders, or directors (“CMS Affiliates”) shall be cumulatively liable for any special, incidental, indirect, punitive or consequential damages or loss of use, profit, revenue or data to you or any third person arising from your use of CMS materials accessed through or downloaded from CMS. This limitation of liability shall:
● Apply regardless of whether (1) you base your claim on contract, tort, statute or any other legal theory, (2) we knew or should have known about the possibility of such damages, or (3) the limited remedies provided in this section fail of their essential purpose; and
● Not apply to any damage that CMS may cause you intentionally or knowingly in violation of these Terms or applicable law, or as otherwise mandated by applicable law that cannot be disclaimed in these Terms.
● Not apply if you have entered into a separate agreement to license a CMS API(s) with a separate Limitation of Liability provision that supersedes this section in relation to that particular CMS API(s).
A. Law and Forum for Legal Disputes
B. These Terms and any claim, cause of action or dispute (“claim”) arising out of or related to these Terms shall be governed by the laws of the District of Columbia, United States, regardless of your country of origin or where you access CMS, and notwithstanding of any conflicts of law principles and the United Nations Convention for the International Sale of Goods. You and CMS agree that all claims arising out of or related to these Terms must be resolved exclusively by a state or federal court located in the District of Columbia, except as otherwise agreed by the parties or as described in the Arbitration Option paragraph below. You and CMS agree to submit to the personal jurisdiction of the courts located within the District of Ciolumbia for the purpose of litigating all such claims. Notwithstanding the above, you agree that CMS shall still be allowed to apply for injunctive remedies (or an equivalent type of urgent legal relief) in any jurisdiction.
C. Arbitration Option
D. For any claim (excluding claims for injunctive or other equitable relief) where the total amount of the award sought is less than $10,000, the party requesting relief may elect to resolve the dispute in a cost effective manner through binding non-appearance-based arbitration. In the event a party elects arbitration, they shall initiate such arbitration through an established alternative dispute resolution (“ADR”) provider mutually agreed upon by the parties. The ADR provider and the parties must comply with the following rules: (a) the arbitration shall be conducted by telephone, online and/or be solely based on written submissions, the specific manner shall be chosen by the party initiating the arbitration; (b) the arbitration shall not involve any personal appearance by the parties or witnesses unless otherwise mutually agreed by the parties; and (c) any judgment on the award rendered by the arbitrator shall be final and may be entered in any court of competent jurisdiction.
Here are some important details about how to read these Terms.
A. Severability
B. If any provision of these Terms is found by a court of competent jurisdiction or arbitrator to be illegal, void, or unenforceable, the unenforceable provision will be modified so as to render it enforceable and effective to the maximum extent possible in order to effect the intention of the provision; if a court or arbitrator finds the modified provision invalid, illegal, void or unenforceable, the validity, legality and enforceability of the remaining provisions of these Terms will not be affected in any way.
C. Language
D. Where CMS has provided you with a translation of the English language version of these Terms, the Privacy Policy, or any other documentation, you agree that the translation is provided for your convenience only and that the English language versions of these Terms, the Privacy Policy, and any other documentation, including additional terms of service for Premium Services, will govern your relationship with CMS.
E. Notices and Service of Process
F. In addition to Section 11.C. (“Notices and Service Messages”), we may notify you via postings on Developer Site. You may contact us here. Or via mail or courier at: Center for Medicare and Medicaid Services ATTN: Legal Department 7500 Security Boulevard, MD 21244, USA. Additionally, CMS accepts service of process at this address. Any notices that you provide without compliance with this section shall have no legal effect.
G. Entire Agreement
H. You agree that these Terms constitutes the entire, complete and exclusive agreement between you and CMS regarding the CMS APIs and supersedes all prior agreements and understandings, whether written or oral, or whether established by custom, practice, policy or precedent, with respect to the subject matter of these Terms. You also may be subject to additional terms and conditions that may apply when you use or purchase or use certain other CMS services, third-party content or third party software.
I. Amendments to these Terms
J. We reserve the right to modify, supplement, or replace the terms of these Terms, effective prospectively upon posting on the Developer Site or notifying you otherwise. For example, we may present a banner on the Developer Site when we have amended these Terms so that you may access and review the changes prior to your continued use of the CMS APIs and developer platform. If you do not want to agree to changes to these Terms, you can terminate these Terms at any time by ceasing use of the APIs and/or closing your Developer Account.
K. No informal waivers, agreements or representations
L. Our failure to act with respect to a breach of these Terms by you or others does not waive our right to act with respect to that breach or subsequent similar or other breaches. Except as expressly and specifically contemplated by these Terms, no representations, statements, consents, waivers or other acts or omissions by any CMS affiliate shall be deemed legally binding on any CMS Affiliate, unless documented in a physical writing hand signed by a duly appointed representative of CMS.
M. No Injunctive Relief
N. In no event shall you seek or be entitled to rescission, injunctive or other equitable relief, or to enjoin or restrain the operation of the CMS developer platform or any APIs, content or other material used or displayed through the CMS developer platform.
O. Beneficiaries
P. Entities other than CMS are not parties, but intended third party beneficiaries of these Terms, with a right to enforce these Terms directly against you.
Q. Assignment and Delegation
R. You may not assign or delegate any rights or obligations under these Terms. Any purported assignment and delegation shall be ineffective. We may freely assign or delegate all rights and obligations under these Terms, fully or partially without notice to you. We may also substitute, by way of unilateral novation, effective upon notice to you, CMS for any third party that assumes our rights and obligations under these Terms.
S. Potential Other Rights and Obligations
T. You may have rights or obligations under local law other than those enumerated here if you are located outside the United States.
If you have questions or comments about these CMS BlueButton API Terms of Use, please contact us {# TODO: create /accounts/ask/terms_of_use #} online or by physical mail at:
Centers for Medicare and Medicaid Services
Attn: BlueButton API Terms of Use Issues
7500 Security Boulevard
Baltimore, MD 21244
USA


Welcome to www.pmt.ng the Online Booking Portal of Peace Mass Transit Ltd, a subsediary of Peace Group Nigeria. PMT is the most popular transport company in Nigeria that delivers safe, comfortable and affordable services in masstransit.
Book online now and enjoy your journey to Aba, Abakaliki, Abakpa, Afikpo, Ajah, Ajegunle, Akure, Bwarri, Calabar, Demorose, Ejigbo, Enugu , Enugu-Ezike, Garriki, Gwagwalada, Ibadan, Ibafo, Ikorodu, Ilorin, Jibowu, Kano, Katsina, Kubwa, Kuje, Mararaba, Minna, Nnewi, Nsukka, Obollo-afor, Ojuelegba, Onitsha, Orile, Oshodi, Owerri, Port-harcourt, Umuahia, Utako, Uyo, Yenagoa, Zuba and many other destinations.For any inquiry, speak to our customer care via:<PHONE_NUMBER>2,<PHONE_NUMBER>6 or SMS:<PHONE_NUMBER>1 or contactUs.
Make reservation online to travel any Nigerian city by taking the following steps now.
Select your departure terminal and your destination terminal from the drop down list, select the date of travel and optionally the number of seats and click SEARCH to view available buses.
Available buses your your route are displayed. Select a Bus Schedule and click NEXT.
Choose your seat(s) from the AVAILABLE(BLUE) seats shown on the picture. Based on your route, number of seats, the charge would be calculated and the amount displayed. Fill in your name, phone number, next-of-kin and other relevant details and click SUBMIT.
Transaction Number, and click PAY NOW to go to InterSwitch webpay interface where you will fill in your ATM card details and effect the payment. An additional service charge of ₦100 would be deducted by InterSwitch. After the confirming the Transaction, you may receive an sms or email from PMT.


The timestamp microservice takes a GET request with a natural language date or unix timestamp, and returns a JSON object containing both the unix timestamp and natural language equivalent
https://slpx-timestamp.herokuapp.com/:time
GET
https://slpx-timestamp.herokuapp.com/{natural-language-date || unix-timestamp}
simply add a date or unix timestamp to the URL
# Note: '%20' is the equivalent of a space, you can use spaces with API # the browser will automatically convert those spaces to '%20' https://slpx-timestamp.herokuapp.com/july%201%202016 https://slpx-timestamp.herokuapp.com/1467331200 # the above will return {"unix":1467331200,"natural":"July 1, 2016"}


Sliding Window Protocol
Window Size
1
2
3
4
End To End Delay (in ms)
Time Out (in ms)
Start
Legend
Data Buffered
No Data Received Yet
Acknowledgement
Data Received
Acknowledgement Recieved


WITNESS LIST Subcommittee on Infrastructure Committee May 11, 1999-8:30A HB 1538 ON: Smith, Lawrance (Texas Department of Transportation), Austin Registering, but not testifying: For: Findeisen, Les (Texas Motor Transportation Association), Austin HB 1616 FOR: Campbell, Helen L. (State Fireman's & Fire Marshal's Association), Austin Registering, but not testifying: For: Cain, Randy (Texas Fire Chiefs Association), Austin HB 2149 ON: Bohslav, Thomas (Texas Department of Transportation), Austin HB 2265 ON: Olson, Ron M. (Union Pacific Railroad), Austin Registering, but not testifying: For: Cron, Richard (Harris County Judge Robert Eckels), Houston HB 3014 ON: Hunt, Darrel (Texas Department of Transportation), Austin HB 3061 Registering, but not testifying: On: McCarley, James (Texas Municipal League - Austin, TX), Dallas Smith, Lawrance (Texas Department of Transportation), Austin HB 3521 FOR: Civitello, Thomas C. (Houston Police Department), Houston Hammerlein, George (Paul Bettencourt, Harris County Tax Assessor-Collector), Houston Matthews, Lt. Gary (Houston Police Department), Houston


This is our Vitamin C Serum, it helps to open pores, reduce pimples and is suitable for oily skin. Want to know what it does to your skin Swipe right to see for yourself what it does to your skin!
A serum that helps minimize the appearance of pores and balance serum production-designed to mix (or blend)
with two other Skin Inc serum to tackle multiple skin concems in one.It combines vitamin C,vitamin B6,vitamin E to balance sebum production in your skin.
patented Japanese seaweed encapsulation technology protects the active ingredientes from exposure to light and oxidation, ensuring stability of ingridients and potency of formulation.
It delivers lasting hydration.
How to Use
Apply 3 drops twice daily after cleansing before applying your moisturizer.Tips
Layer individually or blend with up to two additional Skin Inc serums for powerful, multi-tasking, designed to address your skin_s needs.
Suitable For
Oily/acne-prone skin; Mattiflying; Reducing pore size.
IngredientsWater (Aqua), Butylene Glycol, Glycerin, Pentylene Glycol, Algin, Phenoxyethanol, PVP, Alcaligenes Polysaccharides, Carbomer, Magnesium Ascorbyl Phosphate, Pyridoxine HCL, Tocopherol, Ascorbyl Tetraisopalmitate, Dipotassium Glycyrrhizate.


| Interface | Description |
|---|---|
| DocumentLoader |
A vehicle to load a list of Solr documents into some kind of destination,
such as a SolrServer or MapReduce RecordWriter.
|
| Class | Description |
|---|---|
| GenerateSolrSequenceKeyBuilder |
A command that assigns a record unique key that is the concatenation of the given
baseIdField record field, followed by a running count of the record number within
the current session. |
| LoadSolrBuilder |
A command that loads a record into a SolrServer or MapReduce SolrOutputFormat.
|
| SanitizeUnknownSolrFieldsBuilder |
Command that sanitizes record fields that are unknown to Solr schema.xml by either deleting them
(renameToPrefix is absent or a zero length string), or by moving them to a field prefixed with
the given renameToPrefix (e.g.
|
| SolrClientDocumentLoader |
A vehicle to load a list of Solr documents into a local or remote
SolrClient . |
| SolrLocator |
Set of configuration parameters that identify the location and schema of a Solr server or
SolrCloud; Based on this information this class can return the schema and a corresponding
DocumentLoader . |
| SolrMorphlineContext |
A context that is specific to Solr.
|
| SolrMorphlineContext.Builder |
Helper to construct a
SolrMorphlineContext instance. |
| SolrServerDocumentLoader | Deprecated |
| TokenizeTextBuilder |
A command that uses the embedded Solr/Lucene Analyzer library to generate tokens from a text
string, without sending data to a Solr server.
|
Copyright © 2000-2016 Apache Software Foundation. All Rights Reserved.


{% from "security/_macros.html" import render_field_with_errors, render_field %} {% block head %} {% endblock %}
Already have an account? Log in


Dentist in Salt Lake City. Dr. Brigham Stoker DDS, 144 South 700 East, Suite 2, Salt Lake City, UT 84102 |<PHONE_NUMBER> |
home
staff
reviews
services
office
contact


Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto Expires: July 8, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences January 4, 2015
WebRTC Data Channels draft-ietf-rtcweb-data-channel-13.txt
Abstract
The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer.
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 8, 2015.
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1.              Transferring User Data on a Data Channel . . . . . . . . 11 6.7.        Media is sent using SRTP, and is not specified further here. Non-media data is handled by using SCTP [RFC4960] encapsulated in DTLS. DTLS 1.0 is defined in [RFC4347] and the present latest version, DTLS 1.2, is defined in [RFC6347].
+----------+ | SCTP | +----------+ | DTLS | +----------+ | ICE/UDP | +----------+
Figure 1: Basic stack diagram
The encapsulation of SCTP over DTLS (see [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) provides a NAT traversal solution together with confidentiality, source authentication, and integrity protected transfers. This data transport service operates in parallel to the SRTP media transports, and all of them can eventually share a single UDP port number.
SCTP as specified in [RFC4960] with the partial reliability extension defined in [RFC3758] and the additional policies defined in [I-D.ietf-tsvwg-sctp-prpolicies] provides multiple streams natively with reliable, and the relevant partially-reliable delivery modes for user messages. Using the reconfiguration extension defined in [RFC6525] allows to increase the number of streams during the lifetime of an SCTP association and to reset individual SCTP streams. Using [I-D.ietf-tsvwg-sctp-ndata] allows to interleave large messages to avoid the monopolization and adds the support of prioritizing of SCTP streams.
The remainder of this document is organized as follows: Section 3 and Section 4 provide use cases and requirements for both unreliable and reliable peer to peer data channels; Section 5 discusses SCTP over DTLS over UDP; Section 6 provides the specification of how SCTP should be used by the WebRTC protocol framework for transporting non-media data between WEB-browsers.
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 [RFC2119].
This section defines use cases specific to data channels. Please note that this section is informational only.
U-C 1: A real-time game where position and object state information is sent via one or more unreliable data channels. Note that at any time there may be no SRTP media channels, or all SRTP media channels may be inactive, and that there may also be reliable data channels in use.
U-C 2: Providing non-critical information to a user about the reason for a state update in a video chat or conference, such as mute state.
U-C 3: A real-time game where critical state information needs to be transferred, such as control information. Such a game may have no SRTP media channels, or they may be inactive at any given time, or may only be added due to in-game actions.
U-C 4: Non-realtime file transfers between people chatting. Note that this may involve a large number of files to transfer sequentially or in parallel, such as when sharing a folder of images or a directory of files.
U-C 5: Realtime text chat during an audio and/or video call with an individual or with multiple people in a conference.
U-C 6: Renegotiation of the configuration of the PeerConnection.
U-C 7: Proxy browsing, where a browser uses data channels of a PeerConnection to send and receive HTTP/HTTPS requests and data, for example to avoid local Internet filtering or monitoring.
This section lists the requirements for P2P data channels between two browsers. Please note that this section is informational only.
Req. 1: Multiple simultaneous data channels must be supported. Note that there may be 0 or more SRTP media streams in parallel with the data channels in the same PeerConnection, and the number and state (active/inactive) of these SRTP media streams may change at any time.
Req. 2: Both reliable and unreliable data channels must be supported.
Req. 3: Data channels of a PeerConnection must be congestion controlled; either individually, as a class, or in conjunction with the SRTP media streams of the PeerConnection, to ensure that data channels don't cause congestion problems for these SRTP media streams, and that the WebRTC PeerConnection does not cause excessive problems when run in parallel with TCP connections.
Req. 4: The application should be able to provide guidance as to the relative priority of each data channel relative to each other, and relative to the SRTP media streams. This will interact with the congestion control algorithms.
Req. 5: Data channels must be secured; allowing for confidentiality, integrity and source authentication. See [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch] for detailed info.
Req. 6: Data channels must provide message fragmentation support such that IP-layer fragmentation can be avoided no matter how large a message the JavaScript application passes to be sent. It also must ensure that large data channel transfers don't unduly delay traffic on other data channels.
Req. 7: The data channel transport protocol must not encode local IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon.
Req. 8: The data channel transport protocol should support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for such things as image-file-transfer; Implementations might enforce a reasonable message size limit.
Req. 9: The data channel transport protocol should avoid IP fragmentation. It must support PMTU (Path MTU) discovery and must not rely on ICMP or ICMPv6 being generated or being passed back, especially for PMTU discovery.
Req. 10: It must be possible to implement the protocol stack in the user application space.
The important features of SCTP in the WebRTC context are:
o Usage of a TCP-friendly congestion control.
o The congestion control is modifiable for integration with the SRTP media stream congestion control.
o Support of multiple unidirectional streams, each providing its own notion of ordered message delivery.
o Support of ordered and out-of-order message delivery.
o Supporting arbitrary large user messages by providing fragmentation and reassembly.
o Support of PMTU-discovery.
o Support of reliable or partially reliable message transport.
The WebRTC Data Channel mechanism does not support SCTP multihoming. The SCTP layer will simply act as if it were running on a single-homed host, since that is the abstraction that the DTLS layer (a connection oriented, unreliable datagram service) exposes.
The encapsulation of SCTP over DTLS defined in [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source authenticated, and integrity protected transfers. Using DTLS over UDP in combination with ICE enables middlebox traversal in IPv4 and IPv6 based networks. SCTP as specified in [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and provides the following features for transporting non-media data between browsers:
o Support of multiple unidirectional streams.
o Ordered and unordered delivery of user messages.
o Reliable and partial-reliable transport of user messages.
Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side. The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association. In the WebRTC context, the PPID is used to distinguish between UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in
[I-D.ietf-rtcweb-data-protocol]. Please note that the PPID is not accessible via the Javascript API.
The encapsulation of SCTP over DTLS, together with the SCTP features listed above satisfies all the requirements listed in Section 4.
The layering of protocols for WebRTC is shown in the following Figure 2.
+------+------+------+ | DCEP | UTF-8|Binary| | | data | data | +------+------+------+ | SCTP | +----------------------------------+ | STUN | SRTP | DTLS | +----------------------------------+ | ICE | +----------------------------------+ | UDP1 | UDP2 | UDP3 | ... | +----------------------------------+
Figure 2: WebRTC protocol layers
This stack (especially in contrast to DTLS over SCTP [RFC6083] in combination with SCTP over UDP [RFC6951]) has been chosen because it
o supports the transmission of arbitrary large user messages.
o shares the DTLS connection with the SRTP media channels of the PeerConnection.
o provides privacy for the SCTP control information.
Considering the protocol stack of Figure 2 the usage of DTLS 1.0 over UDP is specified in [RFC4347] and the usage of DTLS 1.2 over UDP in specified in [RFC6347], while the usage of SCTP on top of DTLS is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done as described in Section 5.1.2 of [RFC5764] and SCTP is the only payload of DTLS.
Since DTLS is typically implemented in user application space, the SCTP stack also needs to be a user application space stack.
The ICE/UDP layer can handle IP address changes during a session without needing interaction with the DTLS and SCTP layers. However, SCTP SHOULD be notified when an address changes has happened. In this case SCTP SHOULD retest the Path MTU and reset the congestion state to the initial state. In case of a window based congestion control like the one specified in [RFC4960], this means setting the congestion window and slow start threshold to its initial values.
Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for IPv6.
In general, the lower layer interface of an SCTP implementation should be adapted to address the differences between IPv4 and IPv6 (being connection-less) or DTLS (being connection-oriented).
When the protocol stack of Figure 2 is used, DTLS protects the complete SCTP packet, so it provides confidentiality, integrity and source authentication of the complete SCTP packet.
SCTP provides congestion control on a per-association base. This means that all SCTP streams within a single SCTP association share the same congestion window. Traffic not being sent over SCTP is not covered by the SCTP congestion control. Using a congestion control different from than the standard one might improve the impact on the parallel SRTP media streams.
SCTP uses the same port number concept as TCP and UDP do. Therefore an SCTP association uses two port numbers, one at each SCTP end-point.
The DTLS encapsulation of SCTP packets as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used.
This SCTP stack and its upper layer MUST support the usage of multiple SCTP streams. A user message can be sent ordered or unordered and with partial or full reliability.
The following SCTP protocol extensions are required:
o The stream reconfiguration extension defined in [RFC6525] MUST be supported. It is used for closing channels.
o The dynamic address reconfiguration extension defined in [RFC5061] MUST be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL.
o The partial reliability extension defined in [RFC3758] MUST be supported. In addition to the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the number of retransmissions to zero combined with unordered delivery provides a UDP-like service where each user message is sent exactly once and delivered in the order received.
The support for message interleaving as defined in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.
In the WebRTC context, the SCTP association will be set up when the two endpoints of the WebRTC PeerConnection agree on opening it, as negotiated by JSEP (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via ICE; typically this will be shared via BUNDLE or equivalent with DTLS connections used to key the SRTP media streams.
The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup.
SCTP supports two ways of terminating an SCTP association. A graceful one, using a procedure which ensures that no messages are lost during the shutdown of the association. The second method is a non-graceful one, where one side can just abort the association.
Each SCTP end-point supervises continuously the reachability of its peer by monitoring the number of retransmissions of user messages and test messages. In case of excessive retransmissions, the association is terminated in a non-graceful way.
If an SCTP association is closed in a graceful way, all of its data channels are closed. In case of a non-graceful teardown, all data channels are also closed, but an error indication SHOULD be provided if possible.
SCTP defines a stream as a unidirectional logical channel existing within an SCTP association to another SCTP endpoint. The streams are used to provide the notion of in-sequence delivery and for multiplexing. Each user message is sent on a particular stream, either ordered or unordered. Ordering is preserved only for ordered messages sent on the same stream.
Data channels are defined such that their accompanying application-level API can closely mirror the API for WebSockets, which implies bidirectional streams of data and a textual field called 'label' used to identify the meaning of the data channel.
The realization of a data channel is a pair of one incoming stream and one outgoing SCTP stream having the same SCTP stream identifier. How these SCTP stream identifiers are selected is protocol and implementation dependent. This allows a bidirectional communication.
Additionally, each data channel has the following properties in each direction:
o reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream.
o in-order or out-of-order message delivery for message sent. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream.
o A priority, which is a 2 byte unsigned integer. These priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per the definition of the corresponding stream scheduler supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high") or 1024 ("extra high").
o an optional label.
o an optional protocol.
Please note that for a data channel being negotiated with the protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the above properties are the same in both directions.
Data channels can be opened by using negotiation within the SCTP association, called in-band negotiation, or out-of-band negotiation. Out-of-band negotiation is defined as any method which results in an agreement as to the parameters of a channel and the creation thereof. The details are out of scope of this document. Applications using data channels need to use the negotiation methods consistently on both end-points.
A simple protocol for in-band negotiation is specified in [I-D.ietf-rtcweb-data-protocol].
When one side wants to open a channel using out-of-band negotiation, it picks a stream. Unless otherwise defined or negotiated, the streams are picked based on the DTLS role (the client picks even stream identifiers, the server odd stream identifiers). However, the application is responsible for avoiding collisions with existing streams. If it attempts to re-use a stream which is part of an existing data channel, the addition MUST fail. In addition to choosing a stream, the application SHOULD also determine the options to use for sending messages. The application MUST ensure in an application-specific manner that the application at the peer will also know the selected stream to be used, and the options for sending data from that side.
All data sent on a data channel in both directions MUST be sent over the underlying stream using the reliability defined when the data channel was opened unless the options are changed, or per-message options are specified by a higher level.
The message-orientation of SCTP is used to preserve the message boundaries of user messages. Therefore, senders MUST NOT put more than one application message into an SCTP user message. Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP user message.
The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the interpretation of the "Payload data". The following PPIDs MUST be used (see Section 8):
WebRTC String: to identify a non-empty JavaScript string encoded in UTF-8.
WebRTC String Empty: to identify an empty JavaScript string encoded in UTF-8.
WebRTC Binary: to identify a non-empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob).
WebRTC Binary Empty: to identify an empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob).
SCTP does not support the sending of empty user messages. Therefore, if an empty message has to be sent, the appropriate PPID (WebRTC String Empty or WebRTC Binary Empty) is used and the SCTP user message of one zero byte is sent. When receiving an SCTP user message with one of these PPIDs, the receiver MUST ignore the SCTP user message and process it as an empty message.
The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is deprecated. They were used for a PPID-based fragmentation and reassembly of user messages belonging to reliable and ordered data channels.
If a message with an unsupported PPID is received or some error condition related to the received message is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel. This implies in particular that extensions using additional PPIDs can't be used without prior negotiation.
The SCTP base protocol specified in [RFC4960] does not support the interleaving of user messages. Therefore sending a large user message can monopolize the SCTP association. To overcome this limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to support message interleaving, which SHOULD be used. As long as message interleaving is not supported, the sender SHOULD limit the maximum message size to 16 KB to avoid monopolization.
It is recommended that the message size be kept within certain size bounds as applications will not be able to support arbitrarily-large single messages. This limit has to be negotiated, for example by using [I-D.ietf-mmusic-sctp-sdp].
The sender SHOULD disable the Nagle algorithm (see [RFC1122]) to minimize the latency.
Closing of a data channel MUST be signaled by resetting the corresponding outgoing streams [RFC6525]. This means that if one side decides to close the data channel, it resets the corresponding outgoing stream. When the peer sees that an incoming stream was reset, it also resets its corresponding outgoing stream. Once this is completed, the data channel is closed. Resetting a stream sets the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Streams are available for reuse after a reset has been performed.
[RFC6525] also guarantees that all the messages are delivered (or abandoned) before the stream is reset.
This document does not add any additional considerations to the ones given in [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch].
It should be noted that a receiver must be prepared that the sender tries to send arbitrary large messages.
[NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this document.
]
This document uses six already registered SCTP Payload Protocol Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC Binary Empty". [RFC4960] creates the registry "SCTP Payload Protocol Identifiers" from which these identifiers were assigned. IANA is requested to update the reference of these six assignments to point to this document and change the names of the first four PPIDs. The corresponding dates should be kept.
Therefore these six assignments should be updated to read:
+-------------------------------+----------+-----------+------------+ | Value | SCTP | Reference | Date | | | PPID | | | +-------------------------------+----------+-----------+------------+ | WebRTC String | 51 | [RFCXXXX] | 2013-09-20 | | WebRTC Binary Partial | 52 | [RFCXXXX] | 2013-09-20 | | (Deprecated) | | | | | WebRTC Binary | 53 | [RFCXXXX] | 2013-09-20 | | WebRTC String Partial | 54 | [RFCXXXX] | 2013-09-20 | | (Deprecated) | | | | | WebRTC String Empty | 56 | [RFCXXXX] | 2014-08-22 | | WebRTC Binary Empty | 57 | [RFCXXXX] | 2014-08-22 | +-------------------------------+----------+-----------+------------+
Many thanks for comments, ideas, and text from Harald Alvestrand, Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer Dawkins, Gunnar Hellstrom, Christer Holmberg, Cullen Jennings, Paul Kyzivat, Eric Rescorla, Adam Roach, Irene Ruengeler, Randall Stewart, Martin Stiemerling, Justin Uberti, and Magnus Westerlund.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012.
[I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp-ndata-01 (work in progress), July 2014.
[I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data-protocol-08 (work in progress), September 2014.
[I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-dtls-encaps-07 (work in progress), December 2014.
[I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft-ietf-rtcweb-security-07 (work in progress), July 2014.
[I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf-rtcweb-security-arch-10 (work in progress), July 2014.
[I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 (work in progress), October 2014.
[I-D.ietf-tsvwg-sctp-prpolicies] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp-prpolicies-06 (work in progress), December 2014.
[I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Loreto, S., and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-11 (work in progress), December 2014.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, May 2013.
Authors' Addresses
Randell Jesup Mozilla US
Email<EMAIL_ADDRESS>Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 FI
Email<EMAIL_ADDRESS>Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 DE
Email: tuexen@fh-muenster.de


Drowning man rescued from National Stadium swimming pool dies in hospital
by Agency ReportThe Police in Lagos on Sunday said a 26-year-old man, Sodiq Yusuf, had drowned inside the National Stadium swimming pool, Surulere.
Lagos Police Public Relations Officer, DSP Bala Elkana, said in a statement that a team of policemen was immediately mobilised to the scene.
He said the victim, of No. 26, Horgan Bassey Street, Surulere, was rescued and rushed to Randle General Hospital, Surulere, where he later died.
“The corpse has been deposited at the Mainland General Hospital morgue, Yaba, Lagos, for autopsy.
“Investigation is ongoing,” he said.
(NAN)


@*
* Copyright 2020 HM Revenue & Customs
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*@
@import config.ApplicationConfig
@(memberNinoForm: Form[models.MemberNino], name:String, edit: Boolean)(implicit request: Request[_], messages: Messages, appConfig: ApplicationConfig)
@import uk.gov.hmrc.play.views.html.helpers._
@import views.html.helpers._
@ras_main(title = messages("member.nino.page.title")) {
@messages("back")
@(if(memberNinoForm.hasErrors) errorSummary(Messages("generic.errors_heading"), memberNinoForm))
@messages("member.nino.page.header", name)


wps-js is an open source client library for connecting Javascript client to OGC Web Processing services. This page demonstrates how you can use it. More documentation is available in the 52°North Wiki and on GitHub.


Files CCore/inc/net/SingleBridge.h CCore/src/net/SingleBridge.cpp
This class is similar to the Bridge, but implements point-to-point communication.
class SingleBridge : NoCopy
{
....
public:
SingleBridge();
SingleBridge(PacketFormat to_server_format,PacketFormat to_client_format);
~SingleBridge();
// methods
void setDropRate(uint32 drop_rate,uint32 drop_den);
static StrLen ServerName();
static StrLen ClientName();
// start/stop
friend class StartStopObject<SingleBridge>;
using StartStop = StartStopObject<SingleBridge> ;
};
Once a SingleBridge object is created, it creates and registers a server device and a client device. The server device has the name ServerName(). The client device has the name ClientName(). Both server and client implement the PacketEndpointDevice interface and the PortManager co-interface. The port numbering is trivial: all addresses ports are zero. So you can attach to these devices another protocol devices.
The second constructor allows you to specify packet formats to and from server. You may also set the packet drop rate to simulate the packet loss. Use the method setDropRate(). The drop probability is drop_rate/drop_den.
Default constructor sets some predefined packet formats.
To drive the SingleBridge, you have to start it using the inner class StartStop.


Demystifying Blocks, Procs, and Lambdas
February 1, 2015
Don't run for the hills just yet! Blocks, procs, and lambdas aren't complicated at all. They're just examples of closures in Ruby (aka ways of grouping code we want to run). Knowing how to apply these will keep your code nice and DRY!
Let's start with Blocks!
BLOCKS
These are the most common use of closures you have probably seen in Ruby.
array = [1,2,3]
array.each {|x| puts x*2}
=> [2,4,6]
array.each do |x|
puts x*2
end
You can create a block by wrapping a chunk of code within curly braces {}
or between the words do
and end
. Using the do
-end
syntax requires that the do
, code for the block, and end
all be on separate lines, whereas the code wrapped in the {}
should be in a single line.
PROCS
p =Proc.new {|x| puts x*2}
array.each {&p}
=> [2,4,6]
proc = Proc.new {puts "Hello World"}
proc.call
=> Hello World
p.class
=> Proc
Here let's remark on the differences between blocks and procs.
DIFFERENCES BETWEEN BLOCK AND PROCS
1. Procs are objects. Blocks are not.
2. Procs pass an ampersand argument &p
.
3. Procs are reusable code.
p = Proc.new {|x|puts x*2}
p
is an instance of the Proc class so therefore, we can call methods on it and assign it to variables.
Blocks, on the other hand, are part of the syntax of a method call. You can't use them outside of a method without raising a syntax error.
Why is block lowercased and Proc uppercased?
Proc is capitalized because it is a class in Ruby. However, blocks are lowercased because they aren't classes themselves but rather just a form of Proc.
Lambdas
(Lambdas' counterparts in other languages are called "anonymous functions.")
lam = lambda {|n| n*2}
array.each(&lam)
lam = lambda{puts "Hello World"}
=> Hello World
lam.class
=>
Lambdas may look exactly the same as procs, but there are 2 major differences.
Procs vs. Lambdas
1. Unlike procs, lambdas check the number of arguments passed.
def args(code)
one, two = 1, 2
code.call(one, two)
end
args(Proc.new {|a,b,c| puts "Give me a #{a} and a #{b} and a #{c.class}"})
=> Give me a 1 and a 2 and a NilClass
args(lambda {|a,b,c| puts "Give me a #{a} and a #{b} and a #{c.class}"})
=> ArgumentError: wrong number of arguments (2 for 3)
With procs, extra variables are set to nil
. If there are too many variables, then they are ignored. However lambdas require a specific number of variables. They freak out and raise errors.
2. Lambdas and procs treat the "return" keyword differently.
def proc_return
Proc.new{ return "we just returned from the block"}.call
return "we just returned from the calling method"
end
puts proc_return
=> we just returned from the block
def lam_return
lam = lambda{return "we just returned from the block"}.call
return "we just returned from the calling method"
end
puts lambda_return
=> we just returned from the calling method
In proc_return
, once the method hits a return keyword, it stops the rest of the method and returns Proc.new
.
lambda_return
, on the other hand, when the method hits the lambda to return lambda
, instead of stopping, it keeps going to the next return to output lambda_return
method.This difference is due to the difference between procs and methods.
The proc_return
behaves as if it's part of the calling method. So when return is used within it, it returns from both the block and the calling method.  So when you use return
it exits the block without overriding the calling method.
So between lambdas and procs, procs aren't used often to create blocks because of their finicky response semantics.


Contract and declaration of interest
Declaration of interest Edit your declared interests
Professional affiliations
Company A
Principle employer and role
Company A - Job Role X
Appointments, directorships and consultancies
N/A
Other financial interests
N/A
Close family member appointments, directorships and consultancies
Company B
Close family member other financial interests
N/A


Home
Prices and Hours
About Us
Directions
Testimonies
Sale
New Store Data:
Store Name:
Store Short Name:
Minimum Customer:
Maximum Customer:
Average Cookies:


Module: ActionView::LookupContext::ViewPaths
| Relationships & Source Files | |
| Defined in: | actionview/lib/action_view/lookup_context.rb |
Overview
::ActionView::Helpers related to template lookup using the lookup context information.
Instance Attribute Summary
- #view_paths rw
-
#view_paths=(paths)
rw
Whenever setting view paths, makes a copy so that we can manipulate them in instance objects as we wish.
- #html_fallback_for_js readonly
Instance Method Summary
- #any?(name, prefixes = [], partial = false) ⇒ Boolean (also: #any_templates?)
-
#any_templates?(name, prefixes = [], partial = false)
Alias for #any?.
- #exists?(name, prefixes = [], partial = false, keys = [], **options) ⇒ Boolean (also: #template_exists?)
- #find(name, prefixes = [], partial = false, keys = [], options = {}) (also: #find_template)
- #find_all(name, prefixes = [], partial = false, keys = [], options = {})
- #find_file(name, prefixes = [], partial = false, keys = [], options = {})
-
#find_template(name, prefixes = [], partial = false, keys = [], options = {})
Alias for #find.
-
#template_exists?(name, prefixes = [], partial = false, keys = [], **options)
Alias for #exists?.
-
#with_fallbacks
Adds fallbacks to the view paths.
-
#detail_args_for(options)
private
Compute details hash and key according to user options (e.g.
Instance Attribute Details
#html_fallback_for_js (readonly)
[ GitHub ]107
# File 'actionview/lib/action_view/lookup_context.rb', line 107
attr_reader :view_paths, :html_fallback_for_js
#view_paths (rw)
[ GitHub ]107
# File 'actionview/lib/action_view/lookup_context.rb', line 107
attr_reader :view_paths, :html_fallback_for_js
#view_paths=(paths) (rw)
Whenever setting view paths, makes a copy so that we can manipulate them in instance objects as we wish.
111 112 113
# File 'actionview/lib/action_view/lookup_context.rb', line 111
def view_paths=(paths) @view_paths = ActionView::PathSet.new(Array(paths)) end
Instance Method Details
#any?(name, prefixes = [], partial = false) ⇒ Boolean
Also known as: #any_templates?
133 134 135
# File 'actionview/lib/action_view/lookup_context.rb', line 133
def any?(name, prefixes = [], partial = false) @view_paths.exists?(*args_for_any(name, prefixes, partial)) end
#any_templates?(name, prefixes = [], partial = false)
Alias for #any?.
136
# File 'actionview/lib/action_view/lookup_context.rb', line 136
alias :any_templates? :any?
#detail_args_for(options) (private)
Compute details hash and key according to user options (e.g. passed from
#render
).
161 162 163 164 165 166 167 168 169 170 171 172
# File 'actionview/lib/action_view/lookup_context.rb', line 161
def detail_args_for() # :doc: return @details, details_key if .empty? # most common path. user_details = @details.merge() if @cache details_key = DetailsKey.get(user_details) else details_key = nil end [user_details, details_key] end
#exists?(name, prefixes = [], partial = false, keys = [], **options) ⇒ Boolean
Also known as: #template_exists?
128 129 130
# File 'actionview/lib/action_view/lookup_context.rb', line 128
def exists?(name, prefixes = [], partial = false, keys = [], **) @view_paths.exists?(*args_for_lookup(name, prefixes, partial, keys, )) end
#find(name, prefixes = [], partial = false, keys = [], options = {}) Also known as: #find_template
[ GitHub ]115 116 117
# File 'actionview/lib/action_view/lookup_context.rb', line 115
def find(name, prefixes = [], partial = false, keys = [], = {}) @view_paths.find(*args_for_lookup(name, prefixes, partial, keys, )) end
#find_all(name, prefixes = [], partial = false, keys = [], options = {})
[ GitHub ]124 125 126
# File 'actionview/lib/action_view/lookup_context.rb', line 124
def find_all(name, prefixes = [], partial = false, keys = [], = {}) @view_paths.find_all(*args_for_lookup(name, prefixes, partial, keys, )) end
#find_file(name, prefixes = [], partial = false, keys = [], options = {})
[ GitHub ]120 121 122
# File 'actionview/lib/action_view/lookup_context.rb', line 120
def find_file(name, prefixes = [], partial = false, keys = [], = {}) @view_paths.find_file(*args_for_lookup(name, prefixes, partial, keys, )) end
#find_template(name, prefixes = [], partial = false, keys = [], options = {})
Alias for #find.
118
# File 'actionview/lib/action_view/lookup_context.rb', line 118
alias :find_template :find
#template_exists?(name, prefixes = [], partial = false, keys = [], **options)
Alias for #exists?.
131
# File 'actionview/lib/action_view/lookup_context.rb', line 131
alias :template_exists? :exists?
#with_fallbacks
Adds fallbacks to the view paths. Useful in cases when you are rendering a :file.
140 141 142 143 144 145 146 147 148 149 150
# File 'actionview/lib/action_view/lookup_context.rb', line 140
def with_fallbacks added_resolvers = 0 self.class.fallbacks.each do |resolver| next if view_paths.include?(resolver) view_paths.push(resolver) added_resolvers += 1 end yield ensure added_resolvers.times { view_paths.pop } end


This is a demonstration of the adhesive.js framework that delivers essential components for integration of AngilarJS with the real world.
Make sure to look into the source of this plunk, it explains how the project is structured and how the whole application works.
The framework is proven to work with multiple large-scale mission-critical applications over 6 months before it was release to public, lived through several AngularJS version upgrades since 1.9.3 and demonstrated scalability, great performance and high reliability.
adhesive.js created with developers in mind, it's completely open for any kind of customizations via different patterns, starting with simple configuration to implementation of custom strategies.
Only index module loaded at this point. Click around and see how other modules are being auto-loaded on the fly.


Computer Tennis
Left
Right
Run
Backspin
Player 1
←
→
↓
↑
Player 2
a
d
s
w
Pause
p
press space to continue...


RT @kittylyst: Small excerpt from the new book - https://freecontent.manning.com/classloaders-and-reflection/ (whole book in Early Access at: https://www.manning.com/books/the-well-grounded-java-developer-second-edition) #java #jv…
11/29/2021, 7:11:32 AM
Favs: 0
Retweets: 0
link


Functions | |
| EDMA3_DRV_Result | EDMA3_DRV_create (uint32_t phyCtrllerInstId, const EDMA3_DRV_GblConfigParams *gblCfgParams, const void *miscParam) |
| Create EDMA3 Driver Object. | |
| EDMA3_DRV_Result | EDMA3_DRV_delete (uint32_t phyCtrllerInstId, const void *param) |
| Delete EDMA3 Driver Object. | |
| EDMA3_DRV_Handle | EDMA3_DRV_open (uint32_t phyCtrllerInstId, const EDMA3_DRV_InitConfig *initCfg, EDMA3_DRV_Result *errorCode) |
| Open EDMA3 Driver Instance. | |
| EDMA3_DRV_Result | EDMA3_DRV_close (EDMA3_DRV_Handle hEdma, const void *param) |
| Close the EDMA3 Driver Instance. |
| EDMA3_DRV_Result EDMA3_DRV_create | ( | uint32_t | phyCtrllerInstId, | |
| const EDMA3_DRV_GblConfigParams * | gblCfgParams, | |||
| const void * | miscParam | |||
| ) |
Create EDMA3 Driver Object.
This API is used to create the EDMA3 Driver Object. It should be called only ONCE for each EDMA3 hardware instance.
Init-time Configuration structure for EDMA3 hardware is provided to pass the SoC specific information. This configuration information could be provided by the user at init-time. In case user doesn't provide it, this information could be taken from the SoC specific configuration file edma3_<SOC_NAME>_cfg.c, in case it is available.
This API clears the error specific registers (EMCR/EMCRh, QEMCR, CCERRCLR) and sets the TCs priorities and Event Queues' watermark levels, if the 'miscParam' argument is NULL. User can avoid these registers' programming (in some specific use cases) by SETTING the 'isSlave' field of 'EDMA3_RM_MiscParam' configuration structure and passing this structure as the third argument (miscParam).
After successful completion of this API, Driver Object's state changes to EDMA3_DRV_CREATED from EDMA3_DRV_DELETED.
| phyCtrllerInstId | [IN] EDMA3 Controller Instance Id (Hardware instance id, starting from 0). | |
| gblCfgParams | [IN] SoC specific configuration structure for the EDMA3 Hardware. | |
| miscParam | [IN] Misc configuration options provided in the structure 'EDMA3_DRV_MiscParam'. For default options, user can pass NULL in this argument. |
| EDMA3_DRV_Result EDMA3_DRV_delete | ( | uint32_t | phyCtrllerInstId, | |
| const void * | param | |||
| ) |
Delete EDMA3 Driver Object.
Use this API to delete the EDMA3 Driver Object. It should be called only ONCE for each EDMA3 hardware instance. It should be called ONLY after closing all the EDMA3 Driver Instances.
This API is used to delete the EDMA3 Driver Object. It should be called once for each EDMA3 hardware instance, ONLY after closing all the previously opened EDMA3 Driver Instances.
After successful completion of this API, Driver Object's state changes to EDMA3_DRV_DELETED.
| phyCtrllerInstId | [IN] EDMA3 Phy Controller Instance Id (Hardware instance id, starting from 0). | |
| param | [IN] For possible future use. |
| EDMA3_DRV_Handle EDMA3_DRV_open | ( | uint32_t | phyCtrllerInstId, | |
| const EDMA3_DRV_InitConfig * | initCfg, | |||
| EDMA3_DRV_Result * | errorCode | |||
| ) |
Open EDMA3 Driver Instance.
This API is used to open an EDMA3 Driver Instance. It could be called multiple times, for each possible EDMA3 shadow region. Maximum EDMA3_MAX_REGIONS instances are allowed for each EDMA3 hardware instance. Multiple instances on the same shadow region are NOT allowed.
Also, only ONE Master Driver Instance is permitted. This master instance (and hence the region to which it belongs) will only receive the EDMA3 interrupts, if enabled.
User could pass the instance specific configuration structure (initCfg.drvInstInitConfig) as a part of the 'initCfg' structure, during init-time. In case user doesn't provide it, this information could be taken from the SoC specific configuration file edma3_<SOC_NAME>_cfg.c, in case it is available.
By default, this EDMA3 Driver instance will clear the PaRAM Sets while allocating them. To change the default behavior, user should use the IOCTL interface appropriately.
| phyCtrllerInstId | [IN] EDMA3 Controller Instance Id (Hardware instance id, starting from 0). | |
| initCfg | [IN] Used to Initialize the EDMA3 Driver Instance (Master or Slave). | |
| errorCode | [OUT] Error code while opening DRV instance. |
| EDMA3_DRV_Result EDMA3_DRV_close | ( | EDMA3_DRV_Handle | hEdma, | |
| const void * | param | |||
| ) |
Close the EDMA3 Driver Instance.
This API is used to close a previously opened EDMA3 Driver Instance.
| hEdma | [IN] Handle to the previously opened EDMA3 Driver Instance. | |
| param | [IN] For possible future use |


Acknowledgements
Without the trusted and capable packages Mosflm, CCP4, Scala and XDS
it would clearly be impossible to develop xia2. The author would therefore
like to thank Andrew Leslie, Harry Powell, Phil Evans, Wolfgang Kabsch
and Kay Diederichs for their assistance in using their programs and modi-
fications they have made. In addition, more recent developments such as
Labelit
, Pointless and CCTBX have made the development of xia2 much
more straightforward and the end product more reliable. The author would
therefore like to additionally thank Nick Sauter and Ralf Grosse-Kunstleve
for their help.
Development of a package such as this is impossible without test data,
for which the author would like to thank numerous users, particularly the
Joint Center for Structural Genomics, for publishing the majority of their
raw diffraction data.
During the course of xia2 development the project has been supported
by the UK BBSRC through the e-HTPX project, the EU Framework 6 through
the BioXHit project and most recently by Diamond Light Source. The software
itself is open source, distributed under a BSD license,
but relies on the user having correctly configured and licenced the necessary
data analysis software, the details of which will be discussed shortly.


AWS::RAM::ResourceShare
The
AWS::RAM::ResourceShare
resource is used to create, update, and delete an Amazon ResourceShare. For more
information, see
ResourceShare in the AWS RAM API Reference.
Syntax
To declare this entity in your AWS CloudFormation template, use the following syntax:
JSON
{ "Type" : "AWS::RAM::ResourceShare", "Properties" : { "AllowExternalPrincipals" :
Boolean
, "Name" :String
, "Principals" : [String
, ... ], "ResourceArns" : [String
, ... ], "Tags" : [ Tag, ... ] } }
YAML
Type: "AWS::RAM::ResourceShare" Properties: AllowExternalPrincipals:
Boolean
Name:String
Principals: -String
ResourceArns: -String
Tags: - Tag
Properties
AllowExternalPrincipals
-
Indicates whether principals outside of your organization are allowed in this ResourceShare.
Required: No
Type: Boolean
Update requires: No interruption
Name
-
A descriptive name for the ResourceShare.
Required: Yes
Type: String
Update requires: No interruption
Principals
-
A list of account IDs, organizational unit ARNs, and organization ARN to put into the ResourceShare.
Required: No
Type: List of String values
Update requires: No interruption
ResourceArns
-
The resource ARNs to put into the ResourceShare.
Required: No
Type: List of String values
Update requires: No interruption
Tags
-
The tags on this ResourceShare.
Required: No
Type: List of Resource Tag
Update requires: No interruption
Return Values
Ref
When you pass the logical ID of an
AWS::RAM::ResourceShare
resource to the intrinsic
Ref
function, the function returns the
ARN of the created Amazon ResourceShare, such as
arn:aws:ram:us-east-1:123456789012:resource-share/12345678-1234-1234-1234-12345678
.
For more information about using the
Ref
function, see
Ref.
Fn::GetAtt
Fn::GetAtt
returns a value for a specified attribute of this type.
The following are the available attributes and sample return values.
Arn
-
The Amazon Resource Name (ARN) of the resource share, such as
arn:aws:ram:us-east-1:123456789012:resource-share/12345678-1234-1234-1234-12345678
.
For more information about using
Fn::GetAtt
, see
Fn::GetAtt.
Examples
ResourceShare creation example
The following example creates a new ResourceShare.
JSON
{ "AWSTemplateFormatVersion": "2010-09-09T00:00:00.000Z", "Resources": { "myresourceshare": { "Type": "AWS::RAM::ResourceShare", "Properties": { "Name": "My Resource Share", "ResourceArns": [ "arn:aws:ec2:us-east-1:123456789012:resource-type/12345678-1234-1234-1234-12345678" ], "Principals": [ "210987654321" ], "Tags": [ { "Key": "Key1", "Value": "Value1" }, { "Key": "Key2", "Value": "Value2" } ] } } } }
YAML
AWSTemplateFormatVersion: 2010-09-09 Resources: myresourceshare: Type: "AWS::RAM::ResourceShare" Properties: Name: "My Resource Share" ResourceArns: - "arn:aws:ec2:us-east-1:123456789012:resource-type/12345678-1234-1234-1234-12345678" Principals: - "210987654321" Tags: - Key: "Key1" Value: "Value1" - Key: "Key2" Value: "Value2"
See Also
-
CreateResourceShare in the AWS RAM API Reference


Front-End Capstone
Posted September 28, 2016 by Matt Kraatz
Next week marks the halfway point for my career at Nashville Software School, amazing how quickly that time has passed. To cap our front-end coursework, every student has independently developed a client-side application (hooked up to Firebase) that we are presenting to the entire school tomorrow . With almost two weeks devoted to the task, this was really the first opportunity we had to develop something fully-featured and–dare I say–cool.
Today, each of my classmates presented their MVP as a “soft demo” to just our class, and I must say, I’m very impressed. Among 25 different applications, almost every one had at least one feature or view that wowed the audience and prompted a “how did you do that?!” question at the end of their demo. This struck me as inspirational, that just because your app doesn’t necessarily look as polished as Facebook (and probably has a few bugs under the carpet), doesn’t mean that it isn’t an impressive accomplishment. Everyone in the room had no trouble looking past the shiny exterior and appreciating the individual coding feats that everyone was able to achieve.
Personally, I have a lot of frustrations with my final product, but that doesn’t stop me from being proud of what I’ve been able to accomplish so far. And I am by no means discouraged from continuing to work on this app in my free time over the next three months. That being said, this was a learning experience like no other and I wanted to share a few of my “lessons learned” from this project.
Prioritize features and know when to give up (or ask for help)
While I maintained a fairly extensive Trello board to organize my thoughts and maintain focus, I found myself getting distracted by that “shiny feature over there” more than once. Sometimes I was able to accomplish that feature quickly, sometimes it took me a while, and sometimes I couldn’t get it working at all.  This will be a little easier in a professional environment where I don’t get to determine the priority (the product owner does that), but is still a weakness I need to be aware of and improve upon.
Know how your frameworks work (and cooperate)
A lot of the major challenges I encountered while developing my project were specifically a result of combining TurnJS with AngularJS. See, a feature of TurnJS is to only keep 6 pages of your flipbook in the DOM at any one time (for resource utilization, I think). The problem is, when TurnJS removes that content from the DOM, all of the Angular bindings are destroyed and basically need to be recompiled before added back to the DOM to maintain functionality. The first time this happened, it took me hours to diagnose. After I understood that interaction, it was much easier to troubleshoot future Angular issues, and I started getting pretty creative coming up with workarounds.
Don’t forget to have fun
The best decision I made was to pick an app that I actually had a need for personally. Being able to put myself in the shoes of the user, and work on features and functionality that I specifically have yearned for over the years, made all of the pitfalls and stressful moments much easier to power through.
Curious to check out my app? It’s live here, bugs and all: https://groupme-memories.firebaseapp.com


Bellum Gens is a gaming and esports event organizer and consultant focused on the development and popularization of esports in Bulgaria. We want to make esports a recognizable topic for the business and thus to help the development of all esports project in Bulgaria and on the Balkans. If you take interest in esports and want to advertise through esport, position your brand in tournaments, streams, or other gaming and esports channels, then we can help! Contact us for more information on available opportunities.
Bellum Gens is the organizer of the premier Bellum Gen Elite esports event. First held in the town of Stara Zagora, under the name Bellum Gens Elite - Stara Zagora, BGE brought the top Counter-Strike talent in the region to compete under one roof for a prize pool of $10,000!
Bellum Gens EliteBellum Gens is the organizer of the Esports Business League - a competitive amateur gaming event for the office. Miltiple companies in Bulgaria participated in seasons one and two of the Esports Business League both for fun and team building and to show which company has the best gamers among their employees!
Esports Business LeagueBellum Gens offers a CS:GO team finding and team management application, which allows players to look for teams matching their skill and availability, and team owners to manage their teams' roster and general organization. Because CS:GO is a team game!


| JAMA : A Java Matrix Package |
[ Background ] ..... [ The Package ] ..... [ Request for Comments ] ..... [ Authors ] ..... [ Related Links ]
JAMA is a basic linear algebra package for Java. It provides user-level classes for constructing and manipulating real, dense matrices. It is meant to provide sufficient functionality for routine problems, packaged in a way that is natural and understandable to non-experts. It is intended to serve as the standard matrix class for Java, and will be proposed as such to the Java Grande Forum and then to Sun. A straightforward public-domain reference implementation has been developed by the MathWorks and NIST as a strawman for such a class. We are releasing this version in order to obtain public comment. There is no guarantee that future versions of JAMA will be compatible with this one.
A sibling matrix package, Jampack, has also been developed at NIST and the University of Maryland. The two packages arose from the need to evaluate alternate designs for the implementation of matrices in Java. JAMA is based on a single matrix class within a strictly object-oriented framework. Jampack uses a more open approach that lends itself to extension by the user. As it turns out, for the casual user the packages differ principally in the syntax of the matrix operations. We hope you will take the time to look at Jampack along with JAMA. There is much to be learned from both packages.
Capabilities. JAMA is comprised of six Java classes: Matrix, CholeskyDecomposition, LUDecomposition, QRDecomposition, SingularValueDecomposition and EigenvalueDecomposition.
The Matrix class provides the fundamental operations of numerical inear algebra. Various constructors create Matrices from two dimensional arrays of double precision floating point numbers. Various gets and sets provide access to submatrices and matrix elements. The basic arithmetic operations include matrix addition and multiplication, matrix norms and selected element-by-element array operations. A convenient matrix print method is also included.
Five fundamental matrix decompositions, which consist of pairs or triples of matrices, permutation vectors, and the like, produce results in five decomposition classes. These decompositions are accessed by the Matrix class to compute solutions of simultaneous linear equations, determinants, inverses and other matrix functions. The five decompositions are
The design of JAMA represents a compromise between the need for pure and elegant object-oriented design and the need to enable high performance implementations.
| Object Manipulation | constructors
set elements get elements copy clone |
| Elementary Operations | addition
subtraction multiplication scalar multiplication element-wise multiplication element-wise division unary minus transpose norm |
| Decompositions | Cholesky
LU QR SVD symmetric eigenvalue nonsymmetric eigenvalue |
| Equation Solution | nonsingular systems
least squares |
| Derived Quantities | condition number
determinant rank inverse pseudoinverse |
Example of Use. The following simple example solves a 3x3
linear system Ax=b and computes the
norm of the residual.
double[][] array = {{1.,2.,3},{4.,5.,6.},{7.,8.,10.}};
Matrix
A = new Matrix(array);
Matrix
b = Matrix.random(3,1);
Matrix
x = A.solve(b);
Matrix
Residual = A.times(x).minus(b);
double
rnorm = Residual.normInf();
Reference Implementation. The implementation of JAMA downloadable from this site is meant to be a reference implementation only. As such, it is pedagogical in nature. The algorithms employed are similar to those of the classic Wilkinson and Reinsch Handbook, i.e. the same algorithms used in EISPACK, LINPACK and MATLAB. Matrices are stored internally as native Java arrays (i.e., double[][]). The coding style is straightforward and readable. While the reference implementation itself should provide reasonable execution speed for small to moderate size applications, we fully expect software vendors and Java VMs to provide versions which are optimized for particular environments.
Not Covered. JAMA is by no means a complete linear algebra environment. For example, there are no provisions for matrices with particular structure (e.g., banded, sparse) or for more specialized decompositions (e.g. Shur, generalized eigenvalue). Complex matrices are not included. It is not our intention to ignore these important problems. We expect that some of these (e.g. complex) will be addressed in future versions. It is our intent that the design of JAMA not preclude extension to some of these additional areas.
Finally, JAMA is not a general-purpose array class. Instead, it focuses on the principle mathematical functionality required to do numerical linear algebra. As a result, there are no methods for array operations such as reshaping or applying elementary functions (e.g. sine, exp, log) elementwise. Such operations, while quite useful in many applications, are best collected into a separate array class.
Discussion Group. A discussion group has been established for such comments. Comments and suggestions sent to<EMAIL_ADDRESS>will automatically be sent to the JAMA authors, as well as to all subscribers. To subscribe, send email to<EMAIL_ADDRESS>containing the text subscribe jama your-name in the message body. A public archive of the discussion can be browsed.
[Note: NIST will not use the email addresses provided for any purpose other than the maintenance of this discussion list. Participants may remove themselves at any time by sending an email message to<EMAIL_ADDRESS>containing the text unsubscribe jama in the message body. See the NIST Privacy Policy.]
| Joe Hicklin
Cleve Moler Peter Webb ... from The MathWorks
|
Ronald F. Boisvert
Bruce Miller Roldan Pozo Karin Remington ... from NIST
|
Copyright Notice This software is a cooperative product of The MathWorks and the National Institute of Standards and Technology (NIST) which has been released to the public domain. Neither The MathWorks nor NIST assumes any responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.


Toggle navigation
ΘΤ | Miami University
About
About the ΘΤ Miami Colony
Officers
Active Members
Pledges
Alumni
Past Events
Service
Professional Development
Brotherhood
All
Upcoming Events
Recruit ΘΤ
Resumes
Careers
Contact
{% block content %} {% endblock %} {% block socialmedia %}
Like us on
Facebook
!
Follow us on
Twitter
!
Follow @ThetaTauMU
{% endblock %} {% block license %}
{% endblock %}