Senior US Official: Monitoring events in Hong Kong, condemns “unjustified use of force
by Dhwani MehtaA senior Trump Administration official came out on the wires last minutes, via Reuters, noting that the US are monitoring events in Hong Kong, and condemns "unjustified use of force."
He urged All sides to refrain from violence.
As Trump has said, "the united states expects Beijing to honor its commitments under the Sino-British Joint Declaration and to protect Hong Kong's Freedom, legal system and democratic way of life”, the official added.


How can we use compute farms (supercomputers)?
SLURM is an intermediary between your script and its execution
Slurm commands
squeue
: Get status of job queuesbatch
: Submit batch job (script)srun
: Submit single commandscancel
: Cancel a jobYou need to tell SLURM about your resource usage
Resources
srun -c 1 --mem=2G -t 01:00:00 prog arg arg2 arg3 ...
Resources
#!/bin/bash #SBATCH -c 1 #SBATCH --mem=2G #SBATCH -t 01:00:00 prog arg arg2 arg3
# Doesn't have to have x permission sbatch my_script.sh
Batch scripts can also take arguments
#!/bin/bash #SBATCH -c 1 #SBATCH --mem=2G #SBATCH -t 01:00:00 GENOME=$1 READF=$2 READS=$3 OUTNAME=$4 bwa mem -b -o $4 $1 $2 $3
# Doesn't have to have x permission sbatch my_script.sh genome.fa read1.fq.gz read2.fq.gz alignments.bam


On the day after Christmas, my city-mapping project Majuro.js appeared on the front page of Hacker News. It would be a few days before I found out, because I was out of internet, cell phone, or even radio contact on Arno Atoll, a razor-thin string of tropical islands in the Pacific Ocean.
I only visited Arno for my Christmas vacation, away from the bustling capital of the Marshall Islands, Majuro. I went biking with a GPS, ate from pandanus and coconut trees, and stared up at the stars. I met a Japanese volunteer who lived out there for two years. She is tough as nails, and maybe saved my life. But that's another story.
After I got back to the capital, I visited a hotel restaurant across the street from my apartment to use my national internet card. I found out through a friend's Tweet: "@mapmeld Saw you on HN!" I clicked the link, but Hacker News is often blocked in the Marshall Islands, so I got a 404. Through a mirror site, I was able to see the post was made by Hirvesh, who I didn't know and still don't know outside of GitHub. That part of the story remains a mystery.
I remember walking home with a mix of sun-addled confusion and geeky excitement. I finally had something on Hacker News! And I missed it!
A post on Hacker News gets pasted all over the link-sharing web, which was exciting, but I was looking for commentary or feedback. The best reviews were Hirvesh's own post on Functionn.in and a Japanese-language article on MoonGift.jp.
The downside was that my site wasn't ready. Only a few cities were uploaded, and two were still on their own Heroku instances, not linked from the homepage. Without Google Analytics, I couldn't measure traffic or users' understanding of the site. A linked map from Code for America did have analytics on, and recorded 550 unique visits to the link that week. I downloaded and mapped hundreds of user-drawn neighborhoods from my MongoLab database. It was encouraging that almost all users understood how to change the map selection.
By the time I was online, traffic was abating. Without an easy way to host or share their maps, without any indicator of which cities were ready, those who tried the site quickly moved on. I regretted being so unprepared, even if the visitors were unexpected. Mixed feelings. I decided to take steps to build up the site:
I already had the code to store users' maps. I just needed a button to push. One of my first changes was to make saving a map, like this, quick and easy.
I quickly added links to the separate Philadelphia and Savannah sites on Heroku, and put a star next to missing cities, so users would know what was available. I would have to add to the main site slowly, through my sporadic island internet. On national WiFi cards, internet could cost 10 cents per megabyte. Uploads could fail. I wrote a Python script to shrink building KML maps into CSVs, and a script to load them into the database from another Heroku instance. A database write fails 1-3 times during a large upload, so each time I had internet access, I would find where the upload stopped and resume from there. Eventually I wrote a better script that could handle errors.
I reached the free limit on my database before I could add another major city, like Chicago. MongoLab recommends that Heroku users download and re-upload the entire dataset to upgrade to a paid plan... which wasn't feasible from Majuro Atoll. After worrying over the problem for a couple of weeks, I deleted the entire database and started from scratch on a $20/month plan.
By February I had the promised 15 cities for launch, and today the database has over 3.7 million buildings from 21 cities and counties. There are ten more in the pipeline, plus the whole state of Massachusetts, but I don't have the storage space. The only dataset which I downloaded but can't process yet is a geodatabase from NYC.
I always could embed photos on buildings, but it wasn't discoverable by users. After downloading the Bootstrap docs and working on the problem offline, I put together a simple choice of text, photo, or video. This matches what users expect of a map pop-up, and it works well in Google Earth, too.
I added an eraser marker with code similar to other color-coded markers. When you drop an eraser on a building, it partially disappears. Then when you send the map to the cloud, or download a GeoJSON or KML, that building is left out of your map. Technically what you save is a diff, a list of any color changes or details that are attached to buildings.
The default branch of MajuroJS on GitHub is the gh-pages branch, not the server-side master branch. It was important to me that a user could put a map on GitHub Pages without knowing git. Ideally a beginning user would fork the repo, and use GitHub's online editing to put their map into mybuild.geojson.
I wrote or used open source code to derive several maps from the one mybuild.geojson file. For examples, see Standard Map, 3D View, Editor, and Google Maps.
I learned a lot in building up MajuroJS, with perhaps the most important lesson being: always be ready for a launch! You may not have a chance to talk to your first users.
Make a map today and let me know how it goes. GitHub users can add an issue; Twitter users can tweet @mapmeld.


Backitup Backup your System …
Please select a backup from the list!
Backups could not be determined!


@MarkChristopherWest
Calendar
MixCloud
SoundCloud
GitHub
Resume
Search
Calendar
Click
Schedule a Meeting
to get started.
Items on the agenda this week:


Class: ActionDispatch::Journey::Routes
| Relationships & Source Files | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Instance Chain:
|
|
| Inherits: | Object |
| Defined in: | actionpack/lib/action_dispatch/journey/routes.rb |
Overview
The Routing table. Contains all routes for a system. Routes
can be added to the table by calling #add_route.
Class Method Summary
- .new ⇒ Routes constructor
Instance Attribute Summary
- #anchored_routes readonly
- #custom_routes readonly
- #empty? ⇒ Boolean readonly
- #routes readonly
::Enumerable
- Included
| #many? | Returns |
Instance Method Summary
- #add_route(name, mapping)
- #ast
- #clear
- #each(&block)
- #last
- #length (also: #size)
- #partition_route(route)
- #simulator
-
#size
Alias for #length.
- #clear_cache! private
::Enumerable
- Included
| #compact_blank | Returns a new |
| #exclude? | The negative of the |
| #excluding | Returns a copy of the enumerable excluding the specified elements. |
| #in_order_of | Returns a new |
| #including | Returns a new array that includes the passed elements. |
| #index_by | Convert an enumerable to a hash, using the block result as the key and the element as the value. |
| #index_with | Convert an enumerable to a hash, using the element as the key and the block result as the value. |
| #maximum | Calculates the maximum from the extracted elements. |
| #minimum | Calculates the minimum from the extracted elements. |
| #pick | Extract the given key from the first element in the enumerable. |
| #pluck | Extract the given key from each element in the enumerable. |
| #sole | Returns the sole item in the enumerable. |
| #sum | Calculates a sum from the elements. |
| #without | Alias for Enumerable#excluding. |
| #as_json, | |
| #_original_sum_with_required_identity | We can’t use Refinements here because Refinements with |
::ActiveSupport::EnumerableCoreExt::Constants
- Included
Constructor Details
.new ⇒ Routes
# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 12
def initialize @routes = [] @ast = nil @anchored_routes = [] @custom_routes = [] @simulator = nil end
Instance Attribute Details
#anchored_routes (readonly)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 10
attr_reader :routes, :custom_routes, :anchored_routes
#custom_routes (readonly)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 10
attr_reader :routes, :custom_routes, :anchored_routes
#empty? ⇒ Boolean
(readonly)
[ GitHub ]
# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 20
def empty? routes.empty? end
#routes (readonly)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 10
attr_reader :routes, :custom_routes, :anchored_routes
Instance Method Details
#add_route(name, mapping)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 65
def add_route(name, mapping) route = mapping.make_route name, routes.length routes << route partition_route(route) clear_cache! route end
#ast
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 51
def ast @ast ||= begin nodes = anchored_routes.map(&:ast) Nodes::Or.new(nodes) end end
#clear
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 37
def clear routes.clear anchored_routes.clear custom_routes.clear end
#clear_cache! (private)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 74
def clear_cache! @ast = nil @simulator = nil end
#each(&block)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 33
def each(&block) routes.each(&block) end
#last
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 29
def last routes.last end
#length Also known as: #size
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 24
def length routes.length end
#partition_route(route)
[ GitHub ]# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 43
def partition_route(route) if route.path.anchored && route.path.requirements_anchored? anchored_routes << route else custom_routes << route end end
#simulator
[ GitHub ]#size
Alias for #length.
# File 'actionpack/lib/action_dispatch/journey/routes.rb', line 27
alias :size :length


-->
Data Scientist | Product Enthusiast Stay Curious and Keep Learning!
This website is work in progress! Please check back soon!Xgboost Collaborative Filtering MinHash LSH Jaccard Pearson A hybrid recommendation system was built using Item-Based Collaborative Filtering and XGBoost to predict the ratings for a pair of user and business. RMSE threshold of 0.98 was met. In addition, similar items discovery was done using Local Sensitive Hashing (LSH) and Jaccard similarity.
Market Basket Analysis Frequent Items Apriori Savasere, Omiecinski, Navathe (SON) algorithm Apriori and SON algorithms were implemented to find pairs of items that are frequently bought by users in in Ta Feng grocery dataset. This was built using Python and on top of Apache Spark framework. The implementation was further extended to find frequent triples, quadruples, and so on.
Girvan-Newman Modularity BFS Betweenness A social network graph was constructed using Yelp dataset in which the nodes represented the users and an edge existed if two users reviewed the same business. Girvan-Newman algorithm was implemented to calculate betweenness of edges and form communities based on modularity values.
Bradley-Fayyad-Reina (BFR) Kmeans Discard set Compression set Retained set Bradley-Fayyad-Reina (BFR) algorithm and K-Means clustering algorithm were used to cluster a synthetic dataset with 10 features.
Bloom Filter Flajoret Martin Bloom Filter and Flajolet-Martin algorithms were implemented to estimate whether a user id in the data stream was shown before and to estimate the number of unique users within a window in the data stream.
SVM SMOTE Hamming Loss Multi-class and multi-label classification was done on Anuran Calls dataset using SVM algorithm with Gaussian kernels. SMOTE technique was used as a remedy for class imbalance. Hamming loss, precision, recall, ROC and AUC were used in order to evaluate the classification task.
Linear Regression Hypothesis Testing Linear Regression was used to predict the net hourly electrical energy output for a Power Plant, using features such as Ambient Temperature, Ambient Pressure, Relative Humidity, and Exhaust Vacuum.
L1-penalized SVM K-means Monte-Carlo This dataset had two output classes: "Benign" and "Malignant" with 30 attributes. L1 penalized SVM was used to classify the data. In the next step only 50% of positive and negative classes were used to perform semisupervised learning. Finally k-means clustering was done on the whole training set to label test data.
Data Scientist
Applied Data Science Graduate from USC
Programming & Database: Python, PySpark, R, C++, MySQL, MongoDB
Visualization: Tableau, Plotly, R Shiny
Statistics & Machine Learning: A/B Testing, Linear Regression, Logistic Regression, KNN, Decision Trees, SVM, PCA, K-Means, Apriori
Other Tools: AWS-EC2, AWS-SageMaker, Google Analytics, Google Firebase, BigQuery, Shell Scripting, Git


Chung Hing sam lam
Chung Hing sam lam is a movie starring Brigitte Lin, Takeshi Kaneshiro, and Tony Chiu-Wai Leung. Two melancholy Hong Kong policemen fall in love: one with a mysterious female underworld figure, the other with a beautiful and...


Returns the Dirname, with the same spelling as the actual directory, however with correct upper or lower case.
Directory name. e.g. src
Directories on filesystem
directory name e.g for dirName src and directory name Src it will return Src
scans the current workspace for header files
glob string to search for header files
array of posix relative header file paths
list of headerfiles
Gets the regular non glob like filepaths from a file list including glob patterns.
list of file paths including glob like filepaths
regular filenames
scans the current workspace for source files
glob string to search for source files
array of posix relative sourcefile paths
scans filesystem for files
Array of glob strings
array of posix file paths
Generated using TypeDoc
Checks if the Makefile, Src, Inc and Drivers directories/files are present.


{{ site.tag_text }}
Case Study: {{page.title}}
reading time: {{ page.readingTime }}prep time: {{ page.prepTime }}
environment: {{ page.environment }}
context: {{ page.context }}
leadership traits: {{ page.traitsExplored }}
{{ content }}
Workshop Guidance
Organizing the Workshop
- Ask participants to read the narrative before starting the workshop
- Ask some participants to play the roles of the people mentioned in the case study
- Act it out
- Ask the audience to discuss the performance
Alternatively, you could vary the format to review the narrative as a panel discussion. In this variation, the group can discuss the problems with the situation and how they would address it. It may be a good idea to have at least two or three participants come prepared with a point of view to get the conversation going.
Initial Questions to Raise During the Workshop
- Explore what you (in whatever role) really wants in the situation? Do you want the situation to be different? How?
- If you do, articulate in detail what the future look like for the team?
- What choices do you have to make for yourself if you want to lead the change?

- If you do want to drive change, how do you teal with the reality that you’re not the manager and you’re new? How can you lead, nonetheless?
- What do you need to be honest with yourself in the situation?
- How can you “inspire” the people on the team? Inspiring is about showing enthusiasm, excitement, and energy about the possibilities ahead. It signals energy and personal commitment. Do you see any opportunities here?
- No matter your role in the case study, you come with a lot of competence and skill. What are some ways you could you demonstrate it effectively here?
- How would you articulate a vision for this feature and how to implement it? Who would you enlist to help?
Give Us Feedback!
We want to know how the workshop went. Fork this repo and submit a pull request or just drop an email to Michael Rice.


Blair Peterson
chalmie
PhP?
Ping Pong will count up to your number from 1 with the following exceptions:


Counselling made me Mentally strong and Self-dependent Emotionally
Today I am sharing my experience of counseling. I can feel that I have become mentally strong and self-dependent emotionally; the major credit goes to counseling!Acceptance is more Important than Perfection
Towards the end of my PhD journey, when I ran out of energy, I was left with probably the last leg of the PhD- a few experiments and then thewriting up. The experiments were done in a month, but the paper writing seemed like never ending. It started to stress me out and I became veryanxious as to when it will finish.I thought only success meant happiness but I was wrong.
I am a 4th yr B.Tech and living outside the IIIT Kota campus. Initially, when I started my journey, I had trouble adapting to life in College.After admission ,I felt, I couldn't focus on either. So, I decided to take the help of the counselor at the campus. I came to know about Mr Tapan Jain and began seeing him regarding my troubles. From the first day itself, I knew I was in the company of someone who understood me. He made me feel comfortable.Over coming Fears...
I am a Final Year student currently studying in Computer Science Engineering department. I have been through a very tough time Regarding my placement because the fear of not getting good marks in 7th Sem,.Then I met to counselor Mr.Parikshit . He showed me the right path. And , Now I am happily working in Amazon.


This document provide note and summary of RFC 6376, DomainKeys Identified Mail (DKIM) Signatures.
1. Introduction
RFC 4685 provide a background for the development of DKIM, RFC 5585 provide an overview of the service, and RFC 5863 provide deployment and operations guidance and advice.
The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME), OpenPGP).
1.1. Signing Identity
The signing identity is included as part of the signature header field, and is not required to match an address in any particular header fields.
The message signature is written as a message header field so that neither human recipients nor existing Mail User Agent (MUA) software is confused by signature-related content appearing in the message body.
1.2. Scalability
DKIM is designed to support the extreme scalability requirements that characterize the email identification problem. DKIM compatible with the existing email infrastructure and transparent to the fullest extent possible. There is no dependency on the deployment of any new Internet protocols or services for public-key distribution or revocation. DKIM can be implemented independently of clients in order to reduce deployment time. DKIM can be deployed incrementally and allows delegation of signing to third parties.
1.3. Simple Key Management
DKIM require no certificate authority infrastructure. DKIM currently depends on DNS administration and the security of the DNS system. The Verifier requests the public key from a repository in the domain of the claimed Signer directly rather than from a third party.
1.4. Data Integrity
Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message.
No attempt is made to include encryption as part of the mechanism. Signature verification failure does not force rejection of the message.
2. Terminology and Definitions
- Identity
-
A person, role, or organization.
- Identifier
-
A label that refers to an identity.
- Signing Domain Identifier (SDID)
-
A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming some responsibility for the message by signing it.
- Agent or User Identifier (AUID)
-
A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises an optional <local-part> and a domain name. The domain name is the same as that used for the SDID or is a subdomain of it.
- Signers
-
Signers is an elements in the mail system that sign messages onbehalf of SDID.
- Verifiers
-
Verifiers is an element that verify signatures in the message.
- Identity Assessor
-
An element in the mail system that consumes DKIM’s payload, which is the responsible Signing Domain Identifier (SDID). The Identity Assessor is dedicated to the assessment of the delivered identifier.
- Whitespace
-
There are three forms of whitespace: …. SP = ; Space HTAB = ; Horizontal tab WSP = SP / HTAB ; whitespace LWSP (linear whitespace) = *(WSP / CRLF WSP) ; linear whitespace FWS (folding whitespace) = [*WSP CRLF] 1*WSP ; folding whitespace ….
Common ABNF Tokens
atext = ALPHA / DIGIT / ; Printable US-ASCII "!" / "#" / ; characters not including "$" / "%" / ; specials. Used for atoms. "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" Atom = 1*atext hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) [ [FWS] "=" [ [FWS] "=" ] ] hdr-name = field-name qp-hdr-value = dkim-quoted-printable ; with "|" encoded
Local-part
Local-part = Dot-string / Quoted-string ; MAY be case-sensitive Dot-string = Atom *("." Atom) Quoted-string = DQUOTE *QcontentSMTP DQUOTE QcontentSMTP = qtextSMTP / quoted-pairSMTP qtextSMTP = %d32-33 / %d35-91 / %d93-126 ; i.e., within a quoted string, any ; ASCII graphic or space is permitted ; without blackslash-quoting except ; double-quote and the backslash itself. quoted-pairSMTP = %d92 %d32-126 ; i.e., backslash followed by any ASCII ; graphic (including itself) or SPace
sub-domain
sub-domain = Let-dig [Ldh-str] Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
field-name
Name of header field,
field-name = 1*ftext ftext = %d33-57 / ; Printable US-ASCII %d59-126 ; characters not including ; ":".
dot-atom-text
In the local-part of an email address,
dot-atom-text = 1*atext *("." 1*atext)
qp-section
A single line of quoted-printable-encoded text,
qp-section = [*(ptext / SPACE / TAB) ptext] ptext = hex-octet / safe-char hex-octet = "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; Octet MUST be used for characters > 127, =, ; SPACEs or TABs at the ends of lines, and is ; recommended for any character not listed in ; RFC 2049 as "mail-safe". safe-char = ; any octet with decimal value of 33 through ; 60 inclusive, and 62 through 126. ; Characters not listed as "mail-safe" in ; RFC 2049 are also not recommended.
DKIM-Quoted-Printable
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) ; hex-octet is from RFC 2045 dkim-safe-char = %x21-3A / %x3C / %x3E-7E ; '!' - ':', '<', '>' - '~'
DKIM-Quoted-Printable differs from Quoted-Printable as defined in [RFC2045] in several important ways:
-
Whitespace in the input text, including CR and LF, MUST be encoded. [RFC2045] does not require such encoding, and does not permit encoding of CR or LF characters that are part of a CRLF line break.
-
Whitespace in the encoded text is ignored. This is to allow tags encoded using DKIM-Quoted-Printable to be wrapped as needed. In particular, [RFC2045] requires that line breaks in the input be represented as physical line breaks; that is not the case here.
-
The "soft line break" syntax ("=" as the last non-whitespace character on the line) does not apply.
-
It does not require that encoded lines be no more than 76 characters long (although there may be other requirements depending on the context in which the encoded text is being used).
3. Protocol Elements
Protocol Elements are conceptual parts of the protocol that are not specific to either Signers or Verifiers.
3.1. Selectors
selector = sub-domain *( "." sub-domain )
The key namespace is subdivided using "selectors", to support multiple concurrent public keys per signing domain.
Selectors are needed to support some important use cases. For example:
-
Domains that want to delegate signing capability for a specific address for a given duration to a partner, such as an advertising provider or other outsourced function.
-
Domains that want to allow frequent travelers to send messages locally without the need to connect with a particular MSA.
-
"Affinity" domains (e.g., college alumni associations) that provide forwarding of incoming mail, but that do not operate a mail submission agent for outgoing mail.
Reusing a selector with a new key (for example, changing the key associated with a user’s name) makes it impossible to tell the difference between a message that didn’t verify because the key is no longer valid and a message that is actually forged. For this reason, Signers are ill-advised to reuse selectors for new keys. A better strategy is to assign new keys to new selectors.
3.2. Tag=Value Lists
DKIM uses a simple "tag=value" syntax in several contexts, including in messages and domain signature records.
tag-list = tag-spec *( ";" tag-spec ) [ ";" ] tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] tag-name = ALPHA *ALNUMPUNC tag-value = [ tval *( 1*(WSP / FWS) tval ) ] ; Prohibits WSP and FWS at beginning and end tval = 1*VALCHAR VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON ALNUMPUNC = ALPHA / DIGIT / "_"
-
Values are a series of strings containing either plain text, "base64" text, "qp-section", or "dkim-quoted-printable".
-
The name of the tag will determine the encoding of each value.
-
Unencoded semicolon (";") characters MUST NOT occur in the tag value, since that separates tag-specs.
-
Tags MUST be interpreted in a case-sensitive manner.
-
Values MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity.
-
Tags MUST NOT duplicate, otherwise entire tags list is invalid.
-
Whitespace within a value MUST be retained unless explicitly excluded by the specific tag description.
-
Tag=value pairs that represent the default value MAY be included to aid legibility.
-
Unrecognized tags MUST be ignored.
-
Tag with an empty value explicitly designates the empty string as the value.
3.3. Signing and Verification Algorithms
Two algorithms are defined by this specification at this time: rsa-sha1 and rsa-sha256.
-
Signers MUST implement and SHOULD sign using rsa-sha256.
-
Verifiers MUST implement both rsa-sha1 and rsa-sha256.
-
Other algorithms MAY be defined in the future.
-
Verifiers MUST ignore any signatures using algorithms that they do not implement.
-
The rsa-sha1 computes a message hash using SHA-1 and then the hash is then signed using the RSA algorithm and the Signer’s private key.
-
The rsa-sha256 computes a message hash using SHA-256 and then the hash is signed using the RSA algorithm and the Signer’s private key.
-
Signers MUST use RSA keys of at least 1024 bits for long-lived keys.
-
Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys.
Factors that should influence the key size choice include the following:
-
The practical constraint that large (e.g., 4096-bit) keys might not fit within a 512-byte DNS UDP response packet
-
The security constraint that keys smaller than 1024 bits are subject to off-line attacks
-
Larger keys impose higher CPU costs to verify and sign email
-
Keys can be replaced on a regular basis; thus, their lifetime can be relatively short
-
The security goals of this specification are modest compared to typical goals of other systems that employ digital signatures
3.4. Canonicalization
Canonicalization is a process for converting data that has more than one possible representation into a "standard", "normal", or canonical form.
Canonicalization is only used to prepare the email for signing or verifying; it does not affect the transmitted email in any way.
Two canonicalization algorithms are defined for each of the header and the body, a "simple" and "relaxed" algorithms.
-
A "simple" algorithm tolerates almost no modification.
-
A "relaxed" algorithm tolerates common modifications such as whitespace replacement and header field line rewrapping.
-
A Signer MAY specify either algorithm for header or body.
-
If no canonicalization algorithm is specified by the Signer, the "simple" algorithm defaults for both header and body.
-
Verifiers MUST implement both canonicalization algorithms.
-
The header and body MAY use different canonicalization algorithms.
-
Verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms.
-
Canonicalization algorithms MUST NOT change the transmitted data in any way.
3.4.1. The "simple" Canonicalization Algorithm
-
Header fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified.
-
Header field names MUST NOT be case folded and whitespace MUST NOT be changed.
The "simple" body canonicalization algorithm,
-
Converts multiple CRLF at the end of the body to a single CRLF.
-
If there is no body or no trailing CRLF on the message body, a CRLF is added.
3.4.2. The "relaxed" Canonicalization Algorithm
The "relaxed" header canonicalization algorithm MUST apply the following steps in order:
-
Convert all header field names (not the header field values) to lowercase.
-
Unfold all header field continuation lines, CRLF and WSP, and remove CRLF.
-
Implementations MUST NOT remove the CRLF at the end of the header field value.
-
Convert all sequences of one or more WSP characters to a single SP character.
-
Delete all WSP characters at the end of each unfolded header field value.
-
Delete any WSP characters before and after the colon.
-
The colon separator MUST be retained.
The "relaxed" body canonicalization algorithm MUST apply the following steps (a) and (b) in order:
a. Reduce whitespace:
-
Ignore all whitespace at the end of lines. Implementations MUST NOT remove the CRLF at the end of the line.
-
Reduce all sequences of WSP within a line to a single SP character.
b. Ignore all empty lines at the end of the message body.
-
If the body is non-empty but does not end with a CRLF, a CRLF is added.
3.4.3. Example
A message reading:
A: <SP> X <CRLF> B <SP> : <SP> Y <HTAB><CRLF> <HTAB> Z <SP><SP><CRLF> <CRLF> <SP> C <SP><CRLF> D <SP><HTAB><SP> E <CRLF> <CRLF> <CRLF>
Output for "simple" canonicalization,
A: <SP> X <CRLF> B <SP> : <SP> Y <HTAB><CRLF> <HTAB> Z <SP><SP><CRLF> <CRLF> <SP> C <SP><CRLF> D <SP><HTAB><SP> E <CRLF>
Output for relaxed canonicalization,
a:X <CRLF> b:Y <SP> Z <CRLF> <CRLF> <SP> C <CRLF> D <SP> E <CRLF>
4. The DKIM-Signature Header Field
-
The DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC5322].
-
Its SHOULD NOT be reordered
-
Its SHOULD be prepended to the message
-
The DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the "b=" tag (signature value) of that DKIM-Signature header field MUST be treated as though it were an empty string.
-
Unknown tags in the DKIM-Signature header field MUST be included in the signature calculation
-
Unknown tags MUST be ignored by Verifiers
Tags on the DKIM-Signature header field along with their type and requirement status are shown below.
v= (plain-text; REQUIRED)
sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT
The version of this specification.
-
It MUST have the value "1" for implementations compliant with this version of DKIM.
a= (plain-text; REQUIRED)
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h sig-a-tag-k = "rsa" / x-sig-a-tag-k sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
The algorithm used to generate the signature.
b= (base64; REQUIRED)
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data sig-b-tag-data = base64string
The signature data.
-
Whitespace is ignored in this value and MUST be ignored when reassembling the original signature.
-
The signing process can safely insert FWS in this value in arbitrary places to conform to line-length limits.
bh= (base64; REQUIRED)
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data sig-bh-tag-data = base64string
The hash of the canonicalized body part of the message as limited by the "l=" tag.
-
Whitespace is ignored in this value and MUST be ignored when reassembling the original signature.
-
The signing process can safely insert FWS in this value in arbitrary places to conform to line-length limits.
c= (plain-text; OPTIONAL, default is "simple/simple")
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg ["/" sig-c-tag-alg] sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg x-sig-c-tag-alg = hyphenated-word ; for later extension
Type of canonicalization used to prepare the message for signing.
-
It consists of two names separated by a "slash" (%d47) character, corresponding to the header and body canonicalization algorithms, respectively.
-
If only one algorithm is named, that algorithm is used for the header and "simple" is used for the body. For example, "c=relaxed" is treated the same as "c=relaxed/simple".
d= (plain-text; REQUIRED)
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name domain-name = sub-domain 1*("." sub-domain) ; from [RFC5321] Domain, excluding address-literal
The SDID.
-
It MUST correspond to a valid DNS name under which the DKIM key record is published.
-
When presented with a signature that does not meet these requirements, Verifiers MUST consider the signature as invalid.
-
Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
h= (plain-text; REQUIRED)
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name *( [FWS] ":" [FWS] hdr-name )
A colon-separated list of header field names that presented to the signing algorithm.
-
The field MUST contain the complete list of header fields in the order presented to the signing algorithm.
-
The field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation. By "signing" header fields that do not actually exist, a Signer can allow a Verifier to detect insertion of those header fields after signing and also prevents adding fields with no values.
-
The field MAY contain multiple instances of a header field name, meaning multiple occurrences of the corresponding header field are included in the header hash.
-
The field MUST NOT include the DKIM-Signature header field that is being created or verified but may include others.
-
Folding whitespace (FWS) MAY be included on either side of the colon separator.
-
Header field names MUST be compared against actual header field names in a case-insensitive manner.
i= (dkim-quoted-printable; OPTIONAL; default is "@" + "d=" value)
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
The Agent or User Identifier (AUID).
-
The local-part MAY be omitted, because in some cases a Signer may not be able to establish a verified individual identity.
-
The local-part MAY be drawn from a namespace unrelated to any mailbox.
-
The domain-name MUST be the same as, or a subdomain of, the value of the "d=" tag.
-
The domain-name need not be registered in the DNS — so it might not resolve in a query
-
If no "i=" tag, the Verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag.
-
The Signer MAY choose to use the same namespace for its AUIDs as its users’ email addresses or MAY choose other means of representing its users.
l= (plain-text unsigned decimal integer; OPTIONAL, default is entire body)
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT
The number of octets in the body of the email after canonicalization included in the cryptographic hash, starting from 0 immediately following the CRLF preceding the body.
-
This value MUST NOT be larger than the actual number of octets in the canonicalized message body.
-
The value of the "l=" tag is constrained to 76 decimal digits.
-
Implementers MAY need to limit the actual value expressed to a value smaller than
10^76
, e.g., to allow a message to fit within the available storage space. -
If the body length count is not specified, the entire message body is signed.
-
The body length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the body length count.
-
A body length count of zero means that the body is completely unsigned.
-
Signers wishing to ensure that no modification of any sort can occur should specify the "simple" canonicalization algorithm for both header and body and omit the body length count.
q= (plain-text; OPTIONAL)
sig-q-tag = %x71 [FWS] "=" [FWS] qmethod *([FWS] ":" [FWS] qmethod ) qmethod = "dns/txt" / qtype ["/" qoption] qtype = hyphenated-word ; for future extension qoption = qp-hdr-value
A colon-separated list of query methods used to retrieve the public key.
-
Each query method is of the form "type[/options]", where the syntax and semantics of the options depend on the type and specified options.
-
If there are multiple query mechanisms listed, the choice of query mechanism MUST NOT change the interpretation of the signature.
-
Implementations MUST use the recognized query mechanisms in the order presented.
-
Unrecognized query mechanisms MUST be ignored.
-
Default is "dns/txt", which defines the DNS TXT resource record (RR) lookup algorithm,
-
The only option defined for the "dns" query type is "txt", which MUST be included.
-
-
Verifiers and Signers MUST support "dns/txt".
s= (plain-text; REQUIRED)
sig-s-tag = %x73 [FWS] "=" [FWS] selector
The selector subdividing the namespace for the "d=" tag.
-
Internationalized selector names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
t= (plain-text unsigned decimal integer; RECOMMENDED)
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
The time that this signature was created.
-
The format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone.
-
The value is expressed as an unsigned integer in decimal ASCII.
-
This value is not constrained to fit into a 31- or 32-bit integer.
-
Implementations SHOULD be prepared to handle values up to at least
10^12
(until approximately AD 200,000; this fits into 40 bits). -
To avoid denial-of-service attacks, implementations MAY consider any value longer than 12 digits to be infinite.
-
Leap seconds are not counted.
-
Implementations MAY ignore signatures that have a timestamp in the future.
x= (plain-text unsigned decimal integer; RECOMMENDED)
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
Signature Expiration.
-
Default is no expiration
-
The format is the same as in the "t=" tag, represented as an absolute date, not as a time delta from the signing timestamp.
-
The value is expressed as an unsigned integer in decimal ASCII, with the same constraints on the value in the "t=" tag.
-
Signatures MAY be considered invalid if the verification time at the Verifier is past the expiration date.
-
The verification time should be the time that the message was first received at the administrative domain of the Verifier if that time is reliably available; otherwise, the current time should be used.
-
The value of the "x=" tag MUST be greater than the value of the "t=" tag if both are present.
-
The "x=" tag is not intended as an anti-replay defense.
-
Due to clock drift, the receiver’s notion of when to consider the signature expired may not exactly match what the sender is expecting. Receivers MAY add a 'fudge factor’ to allow for such possible drift.
z= (dkim-quoted-printable; OPTIONAL)
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy *( "|" [FWS] sig-z-tag-copy ) sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value
Copied header fields.
-
A vertical-bar-separated list of selected header fields present when the message was signed, including both the field name and value.
-
Default is null
-
It is not required to include all header fields present at the time of signing.
-
This field need not contain the same header fields listed in the "h=" tag.
-
The header field text itself MUST encode the vertical bar ("|", %x7C) character (i.e., vertical bars in the "z=" text are meta-characters, and any actual vertical bar characters in a copied header field MUST be encoded).
-
All whitespace MUST be encoded, including whitespace between the colon and the header field value.
-
After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field and MUST be removed before decoding.
Example
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=simple; q=dns/txt<EMAIL_ADDRESS>t=1117574938; x=1118006938; h=from:to:subject:date; z=From:foo<EMAIL_ADDRESS>Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
4.1. Key Management and Representation
Parameters to the key lookup algorithm are the type of the lookup (the "q=" tag), the domain of the Signer (the "d=" tag of the DKIM-Signature header field), and the selector (the "s=" tag).
public_key = dkim_find_key(q_val, d_val, s_val)
4.1.1. Textual Representation
The current valid tags are described below. Other tags MAY be present and MUST be ignored by any implementation that does not understand them.
v= (plain-text; RECOMMENDED, default is "DKIM1")
key-v-tag = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31
Version of the DKIM key record.
-
If specified, this tag MUST be set to "DKIM1" (without the quotes).
-
This tag MUST be the first tag in the record.
-
Records beginning with a "v=" tag with any other value MUST be discarded.
-
Verifiers MUST do a string comparison on this value; for example, "DKIM1" is not the same as "DKIM1.0"
h= (plain-text; OPTIONAL, defaults to allowing all algorithms)
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg *( [FWS] ":" [FWS] key-h-tag-alg ) key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg x-key-h-tag-alg = hyphenated-word ; for future extension
A colon-separated list of hash algorithms that might be used.
-
Unrecognized algorithms MUST be ignored.
-
The set of algorithms listed in this tag in each record is an operational choice made by the Signer.
k= (plain-text; OPTIONAL, default is "rsa").
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type key-k-tag-type = "rsa" / x-key-k-tag-type x-key-k-tag-type = hyphenated-word ; for future extension
Key type.
-
Signers and Verifiers MUST support the "rsa" key type.
-
The "rsa" key type indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p=" tag. (Note: the "p=" tag further encodes the value using the base64 algorithm.)
-
Unrecognized key types MUST be ignored.
n= (qp-section; OPTIONAL, default is empty)
key-n-tag = %x6e [FWS] "=" [FWS] qp-section
Notes that might be of interest to a human.
-
No interpretation is made by any program.
-
This tag should be used sparingly in any key server mechanism that has space limitations (notably DNS).
-
This is intended for use by administrators, not end users.
p= (base64; REQUIRED)
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string]
Public-key data.
-
An empty value means that this public key has been revoked.
-
The syntax and semantics of this tag value before being encoded in base64 are defined by the "k=" tag.
-
If a private key has been compromised or otherwise disabled, a Signer might want to explicitly state that it knows about the selector, but all messages using that selector should fail verification.
-
Verifiers SHOULD return an error code for any DKIM-Signature header field with a selector referencing a revoked key.
-
A base64string is permitted to include whitespace (FWS) at arbitrary places; however, any CRLFs MUST be followed by at least one WSP character.
-
Implementers and administrators are cautioned to ensure that selector TXT RRs conform to this specification.
s= (plain-text; OPTIONAL; default is "*").
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type *( [FWS] ":" [FWS] key-s-tag-type ) key-s-tag-type = "email" / "*" / x-key-s-tag-type x-key-s-tag-type = hyphenated-word ; for future extension
A colon-separated list of service types to which this record applies.
-
Verifiers for a given service type MUST ignore this record if the appropriate type is not listed.
-
Unrecognized service types MUST be ignored.
-
Currently defined service types are as follows:
-
"*" matches all service types
-
"email" electronic mail (not necessarily limited to SMTP)
-
This tag is intended to constrain the use of keys for other purposes, should use of DKIM be defined by other services in the future.
t= (plain-text; OPTIONAL, default is no flags set)
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag *( [FWS] ":" [FWS] key-t-tag-flag ) key-t-tag-flag = "y" / "s" / x-key-t-tag-flag x-key-t-tag-flag = hyphenated-word ; for future extension
A colon-separated list of flags.
-
Unrecognized flags MUST be ignored.
-
The defined flags are as follows:
-
y: This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the Signer.
-
s: Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag. That is, the "i=" domain MUST NOT be a subdomain of "d=". Use of this flag is RECOMMENDED unless subdomaining is required.
-
4.1.2. DNS Binding
-
All implementations MUST support this binding.
-
All DKIM keys are stored in a subdomain named "_domainkey". Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com".
-
The query type "q=" in lookup function specify DNS Resource Record. The only option defined in this base specification is "txt", indicating the use of a TXT RR.
-
Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace.
-
TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.
4.2. Computing the Message Hashes
-
The Signer/Verifier MUST compute two hashes: one over the body of the message and one over the selected header fields of the message.
-
Signers MUST compute them in the order shown
-
Verifiers MAY compute them in any order convenient to the Verifier
Steps to compute message hash,
-
The Signer/Verifier MUST hash the message body
-
The body canonicalized using algorithm specified in the "c=" tag
-
The body then truncated to the length specified in the "l=" tag
-
That hash value is then converted to base64 form
-
For Signer, the hash value then inserted into "bh=" tag
-
For Verifier, the hash value then compared with value of "bh=" tag
-
-
The Signer/Verifier MUST pass the following to the hash algorithm in the indicated order,
-
The header fields specified by the "h=" tag, in the order specified in that tag.
-
The header fields then canonicalized using the header canonicalization algorithm specified in the "c=" tag.
-
Each header field MUST be terminated with a single CRLF.
-
All tags and their values in the DKIM-Signature header field are included in the cryptographic hash with the sole exception of the value portion of the "b=" (signature) tag, which MUST be treated as the null string.
-
The DKIM-Signature header field MUST NOT be included in its own "h=" tag, although other DKIM-Signature header fields MAY be signed
-
All tags MUST be included even if they might not be understood by the Verifier.
-
Another considerations when computing hash,
-
When calculating the hash on messages that will be transmitted using base64 or quoted-printable encoding, Signers MUST compute the hash after the encoding, and Verifier MUST incorporate the values into hash before decoding.
-
The hash MUST be computed before transport-level encodings such as SMTP "dot-stuffing" (the modification of lines beginning with a "." to avoid confusion with the SMTP end-of-message marker.
-
DKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content.
-
Message attachments in MIME format MUST be included in the content that is signed.
More formally, pseudo-code for the signature algorithm is:
body-hash = hash-alg (canon-body, l-param) data-hash = hash-alg (h-headers, D-SIG, body-hash) signature = sig-alg (d-domain, selector, data-hash)
where,
body-hash: is the output from hashing the body, using hash-alg.
- hash-alg
-
is the hashing algorithm specified in the "a" parameter.
- canon-body
-
is a canonicalized representation of the body, producedusing the body algorithm specified in the "c" parameter.
- l-param
-
is the length-of-body value of the "l" parameter.
- data-hash
-
is the output from using the hash-alg algorithm, to hashthe header including the DKIM-Signature header, and the body hash.
- h-headers
-
is the list of headers to be signed, as specified in the "h="parameter.
- D-SIG
-
is the canonicalized DKIM-Signature field itself without thesignature value portion of the parameter, that is, an empty parameter value.
- signature
-
is the signature value produced by the signing algorithm.
- sig-alg
-
is the signature algorithm specified by the "a" parameter.
- d-domain
-
is the domain name specified in the "d" parameter.
- selector
-
is the selector value specified in the "s" parameter.
4.3. Input Requirements
Signers and Verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards.
4.4. Output Requirements
For each signature verifying result, output of the DKIM algorithm MUST include the set of:
-
The SDID tag value
-
The result of each signature, which ends in one of three states,
-
SUCCESS: a successful verification
-
PERMFAIL: a permanent, non-recoverable error such as a signature verification failure
-
TEMPFAIL: a temporary, recoverable error such as a DNS query timeout
-
The output MAY include other signature properties or result meta-data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results.
4.5. Signing by Parent Domains
By default, private keys corresponding to a domain can be used to sign messages for any subdomain. For example, a key record for the domain "example.com" can be used to verify messages where the AUID ("i=" tag of the signature) is "sub.example.com", or even "sub1.sub2.example.com".
In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID.
-
If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain.
-
If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.
4.6. Relationship between SDID and AUID
-
DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID) through "i=" tag.
-
Upon successfully verifying the signature, a receive-side DKIM Verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.
4.7. Semantics of Multiple Signatures
4.7.1. Example Scenarios
A Signer might sign a message including all header fields and no "l=" tag (to satisfy strict Verifiers) and a second time with a limited set of header fields and an "l=" tag. Verifiers could then choose which signature they prefer.
A message might also have multiple signatures because it passed through multiple Signers. A common case is expected to be that of a signed message that passes through a mailing list that also signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources.
Another related example of multiple Signers might be forwarding services, such as those commonly associated with academic alumni sites. For example, a recipient might have an address at members.example.org, a site that has anti-abuse protection that is somewhat less effective than the recipient would prefer. Such a recipient might have specific authors whose messages would be trusted absolutely, but messages from unknown authors that had passed the forwarder’s scrutiny would have only medium trust.
4.7.2. Interpretation
If a header field with multiple instances is signed, those header fields are always signed from the bottom up. Thus, it is not possible to sign only specific DKIM-Signature header fields. For example, if the message being signed already contains three DKIM-Signature header fields A, B, and C, it is possible to sign all of them, B and C only, or C only, but not A only, B only, A and B only, or A and C only.
-
A Signer MAY add more than one DKIM-Signature header field using different parameters.
-
Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified.
-
Verifier SHOULD evaluate signatures independently and on their own merits. For example, a Verifier that by policy chooses not to accept signatures with deprecated cryptographic algorithms would consider such signatures invalid.
-
Verifiers MAY process signatures in any order of their choice; for example, some Verifiers might choose to process signatures corresponding to the From field in the message header before other signatures.
-
Verifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the Verifier.
-
To limit potential denial-of-service attacks, Verifiers MAY limit the total number of signatures they will attempt to verify.
-
If a Verifier module reports signatures whose evaluations produced PERMFAIL results, Identity Assessors SHOULD ignore those signatures, acting as though they were not present in the message.
5. Signer Actions
The following steps are performed in order by Signers.
5.1. Determine Whether the Email Should Be Signed and by Whom
-
SUBMISSION servers might only sign messages from users that are properly authenticated and authorized.
-
SUBMISSION servers should not sign Received header fields if the outgoing gateway MTA obfuscates Received header fields, for example, to hide the details of internal topology.
-
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email.
5.2. Select a Private Key and Corresponding Selector Information
Currently, all selectors are equal as far as this specification is concerned, so the decision should largely be a matter of administrative convenience.
A Signer should not sign with a private key when the selector containing the corresponding public key is expected to be revoked or removed before the Verifier has an opportunity to validate the signature.
When rotating to a new key pair, signing should immediately commence with the new private key, and the old public key should be retained for a reasonable validation interval before being removed from the key server.
5.3. Normalize the Message to Prevent Transport Conversions
-
In order to minimize the chances of such breakage, Signers SHOULD convert the message to a suitable MIME content-transfer encoding such as quoted-printable or base64 before signing.
-
If the message is submitted to the Signer with any local encoding that will be modified before transmission, that modification to canonical [RFC5322] form MUST be done before signing. In particular, bare CR or LF characters MUST be converted to the SMTP-standard CRLF sequence before the message is signed.
-
The Signer MUST sign the message as it is expected to be received by the Verifier rather than in some local or internal form.
5.4. Determine the Header Fields to Sign
-
The From header field MUST be signed.
-
Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit.
-
Signers MAY include any other header fields present at the time of signing at the discretion of the Signer
-
Strategies to choose header fields,
-
Sign all existing, non-repeatable header fields.
-
Sign only header fields that are likely to be displayed to or otherwise be likely to affect the processing of the message at the receiver.
-
Sign only "well-known" headers.
-
-
Verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. For this reason, signing fields present in the message such as Date, Subject, Reply-To, Sender, and all MIME header fields are highly advised.
-
The DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed.
-
Signers MAY claim to have signed header fields that do not exist. When computing the signature, the nonexisting header field MUST be treated as the null string. This allows Signers to explicitly assert the absence of a header field; if that header field is added later, the signature will fail.
-
A header field name need only be listed once more than the actual number of that header field in a message at the time of signing in order to prevent any further additions. For example, if there is a single Comments header field at the time of signing, listing Comments twice in the "h=" tag is sufficient to prevent any number of Comments header fields from being appended; it is not necessary (but is legal) to list Comments three or more times in the "h=" tag.
Signers need to be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or otherwise reordered. Trace header fields (such as Received) and Resent-* blocks are the only fields prohibited by [RFC5322] from being reordered. In particular, since DKIM-Signature header fields may be reordered by some intermediate MTAs, signing existing DKIM-Signature header fields is error-prone.
All end-user visible header fields should be signed to avoid possible "indirect spamming". For example, if the Subject header field is not signed, a spammer can resend a previously signed mail, replacing the legitimate subject with a one-line spam.
5.4.1. Recommended Signature Content
Common examples of fields with addresses and fields with textual content related to the body are:
-
From (REQUIRED; see Section 5.4)
-
Reply-To
-
Subject
-
Date
-
To, Cc
-
Resent-Date, Resent-From, Resent-To, Resent-Cc
-
In-Reply-To, References
-
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
-
If the "l=" signature tag is in use, the Content-Type field is also a candidate for being included as it could be replaced in a way that causes completely different content to be rendered to the receiving user.
-
Another class of fields that may be of interest are those that convey security-related information about the message, such as Authentication-Results.
The basic rule for choosing fields to exclude is to select those fields for which there are multiple fields with the same name and fields that are modified in transit. Examples of these are:
-
Return-Path
-
Received
-
Comments, Keywords
Signers SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk.
5.4.2. Signatures Involving Multiple Instances of a Field
-
Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block.
-
Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the "h=" tag of the DKIM-Signature header field and MUST sign such header fields in order from the bottom of the header field block to the top.
-
The Signer MAY include more instances of a header field name in "h=" than there are actual corresponding header fields so that the signature will not verify if additional header fields of that name are added.
Example
If the Signer wishes to sign two existing Received header fields, and the existing header contains:
Received: <A> Received: <B> Received: <C>
then the resulting DKIM-Signature header field should read:
DKIM-Signature: ... h=Received : Received :...
and Received header fields <C> and <B> will be signed in that order.
5.5. Compute the Message Hash and Signature
The Signer MUST compute the message hash as and then sign it using the selected public-key algorithm.
Entities such as mailing list managers that implement DKIM and that modify the message or a header field (for example, inserting unsubscribe information) before retransmitting the message SHOULD check any existing signature on input and MUST make such modifications before re-signing the message.
5.6. Insert the DKIM-Signature Header Field
-
The Signer MUST insert the DKIM-Signature header field created in the previous step prior to transmitting the email.
-
The DKIM-Signature header field MUST be inserted before any other DKIM-Signature fields in the header block.
-
It may be placed before any existing "Received" header fields.
6. Verifier Actions
-
Deferring verification until the message is accessed by the end user is discouraged.
-
MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages.
6.1. Extract Signatures from the Message
-
Verifiers MAY try signatures in any order they like.
-
Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields. In particular, there is reason to believe that some relays will reorder the header fields in potentially arbitrary ways.
-
Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all.
-
A Verifier MAY limit the number of signatures it tries, in order to avoid denial-of-service attacks.
-
If the status is "PERMFAIL", the signature failed and should not be reconsidered.
-
If the status is "TEMPFAIL", the signature could not be verified at this time but may be tried again later.
-
A Verifier MAY either arrange to defer the message for later processing or try another signature; if no good signature is found and any of the signatures resulted in a TEMPFAIL status, the Verifier MAY arrange to defer the message for later processing.
6.1.1. Validate the Signature Header Field
-
Implementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the Verifier to return PERMFAIL (signature syntax error).
-
Verifiers MUST return PERMFAIL (incompatible version) when presented a DKIM-Signature header field with a "v=" tag that is inconsistent with this specification.
-
If any tag listed as "required" in Section 3.5 is omitted from the DKIM-Signature header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (signature missing required tag).
-
If "d=" tag is not same or parent domain of "i=" tag, the DKIM-Signature header field MUST be ignored, and the Verifier should return PERMFAIL (domain mismatch).
-
If the "h=" tag does not include the From header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed).
-
Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired.
6.1.2. Get the Public Key
-
The Verifier MUST validate the key record and MUST ignore any public-key records that are malformed.
A Verifier MUST perform the following steps in a manner that is semantically the same as performing them in the order indicated,
-
The Verifier retrieves the public key using the algorithm in the "q=" tag, the domain from the "d=" tag, and the selector from the "s=" tag.
-
If the query for the public key fails to respond, the Verifier MAY seek a later verification attempt by returning TEMPFAIL (key unavailable).
-
If the query for the public key fails because the corresponding key record does not exist, the Verifier MUST immediately return PERMFAIL (no key for signature).
-
If the query for the public key returns multiple key records, the Verifier can choose one of the key records or may cycle through the key records
-
If the result returned from the query does not adhere to the format defined in this specification, the Verifier MUST ignore the key record and return PERMFAIL (key syntax error).
-
If the "h=" tag exists in the public-key record and the hash algorithm implied by the "a=" tag in the DKIM-Signature header field is not included in the contents of the "h=" tag, the Verifier MUST ignore the key record and return PERMFAIL (inappropriate hash algorithm).
-
If the public-key data (the "p=" tag) is empty, then this key has been revoked and the Verifier MUST treat this as a failed signature check and return PERMFAIL (key revoked).
-
If the public-key data is not suitable for use with the algorithm and key types defined by the "a=" and "k=" tags in the DKIM-Signature header field, the Verifier MUST immediately return PERMFAIL (inappropriate key algorithm).
6.1.3. Compute the Verification
-
Based on the algorithm defined in the "c=" tag, the body length specified in the "l=" tag, and the header field names in the "h=" tag, prepare a canonicalized version of the message. Note that this canonicalized version does not actually replace the original content.
-
Based on the algorithm indicated in the "a=" tag, compute the message hashes from the canonical copy.
-
Verify that the hash of the canonicalized message body computed in the previous step matches the hash value conveyed in the "bh=" tag.
-
If the hash does not match, the Verifier SHOULD ignore the signature and return PERMFAIL (body hash did not verify).
-
-
Verifiers might treat a message that contains bytes beyond the indicated body length with suspicion and can choose to treat the signature as if it were invalid (e.g., by returning PERMFAIL (unsigned content)).
-
Using the signature conveyed in the "b=" tag, verify the signature against the header hash using the mechanism appropriate for the public-key algorithm described in the "a=" tag.
-
If the signature does not validate, the Verifier SHOULD ignore the signature and return PERMFAIL (signature did not verify).
-
-
Signature has correctly verified
6.2. Communicate Verification Results
-
Implementations might choose to add an email header "Authentication-Results" (RFC5451) field to the message before passing it on.
-
Any such header field SHOULD be inserted before any existing DKIM-Signature or preexisting authentication status header fields in the header field block.
6.3. Interpret Result/Apply Local Policy
It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not.
7. Security Considerations
7.1. ASCII Art Attacks
The "relaxed" body canonicalization algorithm may enable certain types of extremely crude "ASCII Art" attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the "simple" body canonicalization algorithm should be used instead.
7.2. Misuse of Body Length Limits ("l=" Tag)
Use of the "l=" tag might allow display of fraudulent content without appropriate warning to end users.
An example of such an attack includes altering the MIME structure, exploiting lax HTML parsing in the MUA, and defeating duplicate message detection algorithms.
To avoid this attack, Signers should be extremely wary of using this tag, and Assessors might wish to ignore signatures that use the tag.
7.3. Misappropriated Private Key
Private keys issued to users, rather than one used by an ADministrative Management Domain (ADMD) itself, create the usual problem of securing data stored on personal resources that can affect the ADMD.
A more secure architecture involves sending messages through an outgoing MTA that can authenticate the submitter using existing techniques (e.g. SMTP Authentication).
7.4. Key Server Denial-of-Service Attacks
Given the low overhead of verification compared with handling of the email message itself, such an attack would be difficult to mount.
7.5. Attacks against the DNS
A DKIM Verifier, while verifying a DKIM-Signature header field, could be prompted to retrieve a key record of an attacker’s choosing. This threat can be minimized by ensuring that name servers, including recursive name servers, used by the Verifier enforce strict checking of "glue" and other additional information in DNS responses and are therefore not vulnerable to this attack.
7.6. Replay/Spam Attacks
A spammer sends a piece of spam through an MTA that signs it, banking on the reputation of the signing domain (e.g., a large popular mailbox provider) rather than its own, and then re-sends that message to a large number of intended recipients.
Partial solutions to this problem involve the use of reputation services to convey the fact that the specific email address is being used for spam and that messages from that Signer are likely to be spam.
However, such measures might be prone to abuse, if, for example, an attacker re-sent a large number of messages received from a victim in order to make the victim appear to be a spammer.
7.7. Limits on Revoking Keys
7.8. Intentionally Malformed Key Records
Verifiers MUST thoroughly verify all key records retrieved from the DNS and be robust against intentionally as well as unintentionally malformed key records.
7.9. Intentionally Malformed DKIM-Signature Header Fields
Verifiers MUST be prepared to receive messages with malformed DKIM-Signature header fields and thoroughly verify the header field before depending on any of its contents.
7.10. Information Leakage
An attacker could determine when a particular signature was verified by using a per-message selector and then monitoring their DNS traffic for the key lookup. This would act as the equivalent of a "web bug" for verification time rather than the time the message was read.
7.11. Remote Timing Attacks
In some cases, it may be possible to extract private keys using a remote timing attack [BONEH03]. Implementations should consider obfuscating the timing to prevent such attacks.
7.12. Reordered Header Fields
Signers that sign any existing DKIM-Signature fields run the risk of having messages incorrectly fail to verify.
7.13. RSA Attacks
Verifiers might avoid this attack by refusing to verify signatures that reference selectors with public keys having unreasonable exponents.


Early Black Friday deals from NOW TV for 2019
Christmas might not be coming early but Black Friday sure has, with NOW TV dropping deals already.
Even though it falls on 29 November this year, the streaming service has announced that they’re offering discounts online and in-store ahead of the famous day of deals known as Black Friday.
Black Friday rolls around every year in the run-up to Christmas, promising fantastic offers on all manner of products the day after Americans celebrate Thanksgiving.
Over time, retailers began to offer deals for longer periods of time instead of just on the day, and this year, NOW TV have done just that.
Black Friday offers from NOW TV
NOW TV Smart Stick and Smart Box with 4K Bundles – up to half price savings on the following products are available in selected retailers only:
Advertisement Advertisement
- NOW TV Smart Stick + One Month Cinema, One Month Entertainment and Sky Sports Day Pass – half price: ERP £15 reduced from £30
- NOW TV Smart Box with 4K + One-month Cinema, One Month Entertainment and Sky Sports Day Pass – half price; ERP £25 reduced from £50
- NOW TV Smart Stick + One Month Sports – half price; ERP £20 reduced from £40
Black Friday Bundles – the following deals are available only on NOWTV.com:
- NOW TV One Month Entertainment Pass + One Month Cinema Pass Bundle – £14.99, which is a saving of 29%
- NOW TV One Month Entertainment Pass + One Month Cinema Pass + One Month Sports Day Pass – £19.99, which is a saving of 35%
- NOW TV One Month Entertainment Pass + One Month Cinema Pass + One Month Kids Pass – £16.99, which is a saving of 32%
- NOW TV Sky Sports Month Pass £20 a month for 6 months – which is a saving of 41%**
The deals include offers on Entertainment, Cinema, Kids and Sports passes, as well as Smart Sticks and Smart Boxes.
Smart Sticks are portable devices which give you access to the films and shows on NOW TV that your pass or passes allow you to watch – provided you’ve got a WIFI connection.
Smart Boxes lets you access the content you can watch on NOW TV via your broadband connection.


Find & share great offers
offerbooth India’s Largest Network of OffersAdvertisements use to go through masses of users across the globe
OfferBooth makes GST easy to use
Our platform helps you to generate leads as per business nature or services offered conveniently, securely and with ease.
Find & share great offers


Features¶
This is a conceptual overview of how SemlogWeb works. We assum familiarity with at least one NoSQL database (in our case we use MongoDB) and basic image processing methods.
Contents
Framework overview¶
Many robotic applications have been built in Virtual Realities and are widely used in researches. However, these are mostly only composed with elementary interface for camera setup and data sampling. Our original intention for SemlogWeb is to bridge the gap between all Virtual Realities and perception model.
The framework contains three components. First is knowledge-based database in which a photorealistic synthetic environment is created for usage of computer vision. The world state and sampled image data are stored in the NoSQL database.
The second component is data processing. Both the Scope Constrain and Data Normalization are available before an synthetic image dataset is generated.
The last component is perception models. SemlogWeb can be connected to many computer vision algorithms. Follow the Demo to go through an example.
Database structure¶
Give the abundant synthetic image data in the Unreal Engine, images are stored by tasks and episodes. For example, one task could be “Clean the table” or “Move the Strawberry jam to the fridge”. Multiple participants would equip VR equipments and finish the task in the virtual environment. One attempt carried by one participant is stored as an episode in the database. Therefore one task (mapped as one database) will contains many episodes (mapped as one collection).


Welcome to the world's greatest collection of banger recipes and killer tips.


Med Aimane S
Frontend and Mobile Developer
Featured work
UI and UX Design
Read more
Frontend coding
Read more
Creativity and Consulting
Read more
Podcasting
Read more
Pub and Tweets
Read more
Art and Activities
Read more


object
IntervalSeq
extends AnyRef
Value Members
-
def
!=
(arg0: AnyRef): Boolean
-
def
!=
(arg0: Any): Boolean
-
def
##
(): Int
-
def
==
(arg0: AnyRef): Boolean
-
def
==
(arg0: Any): Boolean
-
def
apply
[T]
()(implicit arg0: (T) ⇒ Ordered[T]): To[T]
-
def
apply
[T]
(intervals: From[T])(implicit arg0: (T) ⇒ Ordered[T]): IntervalSeq[T]
-
def
asInstanceOf
[T0]
: T0
-
implicit def
canBuildFrom
[T]
(implicit arg0: (T) ⇒ Ordered[T]): CanBuildFrom[From[T], Elem[T], To[T]]
-
def
clone
(): AnyRef
-
def
eq
(arg0: AnyRef): Boolean
-
def
equals
(arg0: Any): Boolean
-
def
finalize
(): Unit
-
def
getClass
(): java.lang.Class[_]
-
def
hashCode
(): Int
-
def
isInstanceOf
[T0]
: Boolean
-
def
ne
(arg0: AnyRef): Boolean
-
def
newBuilder
[T]
(ordering: Ordering[Interval[T]])(implicit arg0: (T) ⇒ Ordered[T]): Builder[Elem[T], To[T]]
-
def
notify
(): Unit
-
def
notifyAll
(): Unit
-
def
synchronized
[T0]
(arg0: ⇒ T0): T0
-
def
toString
(): String
-
def
unapply
[T]
(intervalSeq: IntervalSeq[T])(implicit arg0: (T) ⇒ Ordered[T]): Some[(Seq[Interval[T]], Ordering[Interval[T]])]
-
def
wait
(): Unit
-
def
wait
(arg0: Long, arg1: Int): Unit
-
def
wait
(arg0: Long): Unit
Inherited from AnyRef
Inherited from Any
IntervalSeq
コンパニオンオブジェクト


h2load - HTTP/2 benchmarking tool - HOW-TO¶
h2load(1) is benchmarking tool for HTTP/2 and HTTP/1.1. If built with spdylay (http://tatsuhiro-t.github.io/spdylay/) library, it also supports SPDY protocol. It supports SSL/TLS and clear text for all supported protocols.
Compiling from source¶
h2load is compiled alongside nghttp2 and requires that the
--enable-apps
flag is passed to ./configure
and required
dependencies are
available during compilation. For details on compiling, see nghttp2:
Building from Git.
Basic Usage¶
In order to set benchmark settings, specify following 3 options.
-n
- The number of total requests. Default: 1
-c
- The number of concurrent clients. Default: 1
-m
- The max concurrent streams to issue per client. Default: 1
For SSL/TLS connection, the protocol will be negotiated via ALPN/NPN.
You can set specific protocols in --npn-list
option. For
cleartext connection, the default protocol is HTTP/2. To change the
protocol in cleartext connection, use --no-tls-proto
option.
For convenience, --h1
option forces HTTP/1.1 for both
cleartext and SSL/TLS connections.
Here is a command-line to perform benchmark to URI https://localhost using total 100000 requests, 100 concurrent clients and 10 max concurrent streams:
$ h2load -n100000 -c100 -m10 https://localhost
The benchmarking result looks like this:
finished in 7.08s, 141164.80 req/s, 555.33MB/s
requests: 1000000 total, 1000000 started, 1000000 done, 1000000 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 1000000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic:<PHONE_NUMBER> bytes total, 11023424 bytes headers (space savings 93.07%),<PHONE_NUMBER> bytes data
min max mean sd +/- sd
time for request: 15.31ms 146.85ms 69.78ms 9.26ms 92.43%
time for connect: 1.08ms 25.04ms 10.71ms 9.80ms 64.00%
time to 1st byte: 25.36ms 184.96ms 79.11ms 53.97ms 78.00%
req/s (client) : 1412.04 1447.84 1426.52 10.57 63.00%
See the h2load manual page OUTPUT section for the explanation of the above numbers.
Flow Control¶
HTTP/2 and SPDY/3 or later employ flow control and it may affect benchmarking results. By default, h2load uses large enough flow control window, which effectively disables flow control. To adjust receiver flow control window size, there are following options:
Multi-Threading¶
Sometimes benchmarking client itself becomes a bottleneck. To remedy
this situation, use -t
option to specify the number of native
thread to use.
-t
- The number of native threads. Default: 1
Selecting protocol for clear text¶
By default, if http:// URI is given, HTTP/2 protocol is used. To
change the protocol to use for clear text, use -p
option.
Multiple URIs¶
If multiple URIs are specified, they are used in round robin manner.
Note
Please note that h2load uses scheme, host and port in the first URI and ignores those parts in the rest of the URIs.
UNIX domain socket¶
To request against UNIX domain socket, use --base-uri
, and
specify unix:
followed by the path to UNIX domain socket. For
example, if UNIX domain socket is /tmp/nghttpx.sock
, use
--base-uri=unix:/tmp/nghttpx.sock
. h2load uses scheme, host and
port in the first URI in command-line or input file.


This module contains various mathematical utilities.
Rotation related functions.
| rotation_matrix(angle, axis[, dim, dtype]) | Returns rotation matrix for specified degree angle and coordinate axis of rotation. |
| rotation_matrix_from_cross_prod(a, b) | Returns the rotation matrix which rotates the vector a onto the the vector b. |
| axis_angle_from_cross_prod(a, b) | Returns the (axis, radian_angle) rotation which rotates the vector a onto the the vector b. |
| axis_angle_from_rotation_matrix(rm) | Converts 3x3 rotation matrix to axis and angle representation. |
| axis_angle_to_rotation_matrix(direction, angle) | Convert 3D axis and angle of rotation to 3x3 rotation matrix. |


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Tree
Deprecated
Index
Help
Prev Package
Next Package
Frames
No Frames
All Classes
Package com.microblink.core.internal.services
Interface Summary
Interface
Description
ProductIntelService
ProductIntelServices
PromotionService
PromotionServices
ReceiptService
ReceiptServices
Class Summary
Class
Description
HeaderInterceptor
LookupSearch
OfflineInterceptor
ProductIntelLookupResults
ProductIntelProduct
ProductIntelResult
ProductIntelResults
ProductIntelServiceImpl
PromoInfo
PromotionException
PromotionQuery
Promotions
PromotionServiceImpl
QualifyingPromotion
Receipt
ReceiptImage
ReceiptInfo
ReceiptProduct
ReceiptPromotion
ReceiptPromotionInstance
ReceiptServiceImpl
SearchByAudienceUser
ServiceGenerator
Skip navigation links
Overview
Package
Class
Tree
Deprecated
Index
Help
Prev Package
Next Package
Frames
No Frames
All Classes


Class WalletType
Base type for implementing custom wallet types.
Inheritance
Namespace: Hyperledger.Indy.WalletApi
Assembly: Hyperledger.Indy.Sdk.dll
Syntax
public abstract class WalletType : Object
Constructors
WalletType()
Initializes a new WalletType.
Declaration
protected WalletType()
Methods
Close(Int32)
Allows an implementer to close a wallet.
Declaration
public abstract ErrorCode Close(int walletHandle)
Parameters
| Type | Name | Description |
|---|---|---|
| System.Int32 | walletHandle | The handle of the wallet to close. |
Returns
| Type | Description |
|---|---|
| ErrorCode | An ErrorCode value indicating the outcome of the operation. |
Remarks
When implementing a custom wallet this method is responsible for closing the wallet with the handle allocated earlier in the Open(String, String, String, String, out Int32) method.
Create(String, String, String)
Allows an implementer to create a new wallet.
Declaration
public abstract ErrorCode Create(string name, string config, string credentials)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | name | The name of the wallet to create. |
| System.String | config | The configuration for the wallet. |
| System.String | credentials | The credentials for the wallet. |
Returns
| Type | Description |
|---|---|
| ErrorCode | An ErrorCode value indicating the outcome of the operation. |
Remarks
When implementing a custom wallet this method is responsible for creating the new wallet and storing its configuration and credentials.
Delete(String, String, String)
Allows an implementer to delete a wallet.
Declaration
public abstract ErrorCode Delete(string name, string config, string credentials)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | name | The name of the wallet being deleted |
| System.String | config | The configuration of the wallet. |
| System.String | credentials | The credentials of the wallet. |
Returns
| Type | Description |
|---|---|
| ErrorCode | An ErrorCode value indicating the outcome of the operation. |
Remarks
When implementing a custom wallet this method is responsible for deleting a wallet created
earlier via the Create(String, String, String) method. The value of the
credentials
parameter should be used to control access whether or not
the wallet can be deleted.
GetWalletByHandle(Int32)
Gets a wallet by its handle.
Declaration
protected abstract ICustomWallet GetWalletByHandle(int walletHandle)
Parameters
| Type | Name | Description |
|---|---|---|
| System.Int32 | walletHandle | The handle of the wallet. |
Returns
| Type | Description |
|---|---|
| ICustomWallet | The wallet instance associated with the handle. |
Open(String, String, String, String, out Int32)
Allows an implementer to open a wallet.
Declaration
public abstract ErrorCode Open(string name, string config, string runtimeConfig, string credentials, out int walletHandle)
Parameters
| Type | Name | Description |
|---|---|---|
| System.String | name | The name of the wallet to open. |
| System.String | config | The configuration for the wallet. |
| System.String | runtimeConfig | The runtime configuration for the wallet. |
| System.String | credentials | The credentials of the wallet. |
| System.Int32 | walletHandle | The handle assigned to the wallet. |
Returns
| Type | Description |
|---|---|
| ErrorCode | An ErrorCode value indicating the outcome of the operation. |
Remarks
When implementing a custom wallet this method is responsible for opening the wallet and returning
a handle for the opened wallet. The value of the runtimeConfig
parameter
should override any corresponding values provided in the config
parameter
and value of the credentials
parameter should be used to control access
to the wallet.


Aston Martin Has Something Special Coming This Week
The next chapter in the Aston Martin Wings Series is upon us.
by Noah JosephThe British are no strangers to the pursuit of speed – whether it comes in the form of a high-powered sports car (like an Aston Martin) or a supersonic jet aircraft (like the Concorde). Now the two are coming together in what appears to be a new special edition.
Aston Martin and British Airways tweeted out this teaser of what looks like a DBS Superleggera that's somehow supposed to encapsulate the spirit of the Concorde – that ground- and sound-barrier-braking passenger jet that was jointly developed and operated by the British and the French.
https://twitter.com/British_Airways/status/1197786890704969728
As little as the animated teaser reveals, Autocar reports that it'll be a special edition of the DBS, decked out in white with the red and blue of the Union Jack flag.
Only a couple of weeks ago, Aston Martin announced the creation of a new Wings Series, leveraging the automaker's ties to the aerospace industry with a line of special editions. Aston previously put out the Vanquish S Red Arrows Edition (pictured at bottom) in 2017 to celebrate the Royal Air Force's aerobatics squadron, similar to the V8 Vantage S Blades Edition (below) it produced previously. This, then, would appear to represent the next chapter in the Wings Series, and the first since its official formation.
"Aston Martin will always be synonymous with aviation, from our wings logo to the heritage of our manufacturing sites across the UK," said Aston chief Andy Palmer in the Wings Series announcement, referring to the three out of four of its British factories that are built on the sites of former RAF air bases. "The Vanquish S Red Arrows edition was a great success for everyone concerned and I look forward to seeing our future aviation-related special editions."
Whatever form it ultimately takes, we'll find out soon enough. The reveal is scheduled for this Tuesday, November 26, at the Aston Martin dealer in Bristol – the same town in which the last Concorde ever flown is on permanent display.


MCKENNA MUNDEN
About
Portfolio
Portraits
Fashion
Latest Project
Contact
FASHION PHOTOGRAPHY
Get in Contact
Lets capture some beautiful memories to last a lifetime.
CONTACT ME


page2
|
page3
|
page1
this is how we want our website to look we
now we will see the media file and its use in the page
we will be studing about the flex box
div1
div2
div3
div4
div5
light box
X
Lightbox content
we will see about verious animations in here.
click me


This webpage is a Monte Carlo simulator for the "Protocol Assimilation"
mechanic in Girls Frontline. The goal is to allow players to test strategies for capturing Sangvis Ferri units.
simulator_constants.js
.
If you find a great strategy, feel free to file an issue or a pull request :).
| Term (In Chinese) | Definition |
|---|---|
| Protocol Assimilation (协议同归) | The name of the system for capturing Sangvis Ferri units and turning them into "Coalition" units. |
| "Pool"/"Box" | The pool of SF units that can be captured. As of 2020/08, these pools have always had one 3* (ringleader), 28 2*, and 71 1* units. The player can only reset the pool after capturing the ringleader. |
| "Map" | A display of three random units from the current remaining pool that the player can use an EMP on to attempt to capture. |
| EMP (电子脉冲) | Free resource generated from the Protocol Assimilation Command Center for attempting to capture SF units. At max facility level, these are generated every 12 hours, and have a softcap of 14. |
| Extra EMP (超导脉冲) | EMPs obtained from missions, achievements, and events. These are stored outside of the softcap. |
| Cooperation Request Contract (协力委托书) | Contracts for capturing random units from the remaining pool, not limited to the current map. Some players refer to this as "Super EMP" or "Svarogs". |
For more information, please read the following infographics:
The number in the parentheses is the standard deviation of P(At Least One Ringleader Captured)
,
with population N
equal to the number of result buckets.
In other words, "how many Cooperative Request Contracts do I need if my luck is the worst?"
If an iteration has reset the pool once, then its "Number of Remaining Units in the First Pool" is counted as zero.
In other words, "how many Cooperative Request Contracts do I need if my luck is medium?"
Let x = EMPs used, y = contracts, n(x) = number of remaining units in the first pool after x EMPs.
Let A(x) = at least one ringleader captured with x EMP, B(x, y) = at least one ringleader captured with x EMP and y contracts.
P(B(x, y)) = 0.5
P(~B(x, y)) = 1 - P(B(x, y)) = 1 - 0.5 = 0.5
P(~B(x, y))
= P(~B(x, y) ∩ A(x)) + P(~B(x, y) ∩ ~A(x))
= P(A(x)) * P(~B(x, y) | A(x)) + P(~A(x)) * P(~B(x, y) | ~A(x))
~B(x, y) | A(x) can never happen, so P(~B(x, y) | A(x)) = 0
Therefore, P(~A(x)) * P(~B(x, y) | ~A(x)) = 0.5
P(~B(x, y) | ~A(x)) = {
0 iff n = 0
(1 - 1 / n(x))^y otherwise [this is assuming that all strategies reset boxes immediately]
}
We can ignore P(~A(x)) = 0 and n(x) = 0 because it's clear that y = 0 in those cases.
Suppose that P(~A(x)) > 0 and n(x) > 0...
P(~B(x, y) | ~A(x)) = 0.5 / P(~A(x))
(1 - 1 / n(x))^y = 0.5 / P(~A(x))
y = log(0.5 / P(~A(x))) / log(1 - 1 / n(x))
This may be greater than one, which indicates that duplicates may be captured.
This may be greater than one, which indicates that duplicates may be captured.
This may be greater than one, which indicates that duplicates may be captured.


Policy paper
Workload challenge for schools: government response
This was published under the 2010 to 2015 Conservative and Liberal Democrat coalition government
Government response to the workload challenge, a review of the unnecessary and unproductive parts of teachers' workloads.
Documents
Ref:
DFE-00058-2015
PDF
,
595KB
,
23 pages