Package Format‌ Clause Samples

Package Format‌. Interested Parties shall arrange their AMS Response package into the sections as set forth in section 5.2 and adhere to the following format requirements: 1. The Interested Party is required to submit its AMS Response package in an electronic format via email. Emails must be titled in the subject line with the Pre-Solicitation Number ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ and Interested Party’s Name. 2. Electronic copies of the AMS Response package shall be compatible with the latest version of Microsoft Office® and the filename should include the Interested Party’s Name. Further, Microsoft Excel spreadsheets shall be submitted in Microsoft Excel format, and not in a scanned Microsoft Word or Adobe PDF file. 3. A cover sheet shall be included in the AMS Response package, clearly marked with date of the package, title, Pre-Solicitation number ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇, the Interested Party's name, and company’s point of contact name for this AMS Response Package. 4. Costly, complex presentations are neither required nor desired. The Interested Party shall minimize the use of scanned images and keep embedded graphics as simple as possible. 5. The Interested Party shall not embed sound or video files into the package files. 6. The Interested Party shall perform an anti-virus/anti-malware scan prior to package submission.
View SourceView Similar (3)

Related to Package Format‌

  • Escrow Format Specification Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-▇▇▇▇▇-▇▇▇▇▇▇▇-registry-data-escrow, see Part A, Section 9, reference 1 of this Specification and draft-▇▇▇▇▇-▇▇▇▇▇▇▇-dnrd-objects-mapping, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-8 character encoding will be used.

  • Proposal Format To facilitate efficiency and consistency in proposal evaluation the following is mandatory. Proposals which do not follow this direction may be rejected as non-responsive and thus ineligible for award.

  • ODUF Packing Specifications 6.3.1 A pack will contain a minimum of one message record or a maximum of 99,999 message records plus a pack header record and a pack trailer record. One transmission can contain a maximum of 99 packs and a minimum of one pack.

  • Invoice Format Invoices furnished by Contractor under this Agreement must be in a form acceptable to the Controller and City, and must include a unique invoice number. Payment shall be made by City as specified in 3.3.6 or in such alternate manner as the Parties have mutually agreed upon in writing.

  • File Format Standard Registry Operator (optionally through the CZDA Provider) will provide zone files using a subformat of the standard Master File format as originally defined in ▇▇▇ ▇▇▇▇, Section 5, including all the records present in the actual zone used in the public DNS. Sub-format is as follows: Each record must include all fields in one line as: <domain-name> <TTL> <class> <type> <RDATA>. Class and Type must use the standard mnemonics and must be in lower case. TTL must be present as a decimal integer. Use of /X and /DDD inside domain names is allowed. All domain names must be in lower case. Must use exactly one tab as separator of fields inside a record. All domain names must be fully qualified. No $ORIGIN directives. No use of “@” to denote current origin. No use of “blank domain names” at the beginning of a record to continue the use of the domain name in the previous record. No $INCLUDE directives. No $TTL directives. No use of parentheses, e.g., to continue the list of fields in a record across a line boundary. No use of comments. No blank lines. The SOA record should be present at the top and (duplicated at) the end of the zone file. With the exception of the SOA record, all the records in a file must be in alphabetical order. One zone per file. If a TLD divides its DNS data into multiple zones, each goes into a separate file named as above, with all the files combined using tar into a file called <tld>.zone.tar.