Does anyone know the format of the MAPI property PR_SEARCH_KEY?
The online documentation has this to say about it:
The search key is formed by
concatenating the address type (in
uppercase characters), the colon
character ':', the e-mail address in
canonical form, and the terminating
null character.
And the exchange document MS-OXOABK says this:
The PidTagSearchKey property of type
PtypBinary is a binary value formed by
concatenating the ASCII string "EX: "
followed by the DN for the object
converted to all upper case, followed
by a zero byte value.
However all the MAPI messages I've seen with this property have it as some sort of binary 16 byte sequence that looks like a GUID. Does anyone else have any more information about it? Is it always 16 bytes?
Thanks!
I believe that the property PR_SEARCH_KEY will be of different formats for different objects (as alluded to by Moishe).
A MAPI message object will have a unique value assigned on creation for PR_SEARCH_KEY, however if the object is copied this property value is copied also. I presume when you reply to an e-mail, Exchange will assign the PR_SEARCH_KEY value to be the original message's value.
You will need to inspect each object type to understand how the PR_SEARCH_KEY is formed but I doubt if it's always 16 bytes for all MAPI types.
This link USENET discussion has a good discussion with Dmitry Streblechenko involved who is an expert on Extended MAPI.
The sentence before the ones you quoted from the online docs reads, "MAPI uses specific rules for constructing search keys for message recipients" which makes me think that it's talking about the PR_SEARCH_KEY property on MAPI_MAILUSER objects -- or at least not on MAPI_MESSAGE objects.
Related
I already asked what I needed at the title. I want to generate using either PHP or javascript.
I think the class name and some properties are used to build the objectId but someone may already know how its done that could share here?
The Parse Server generates the objectId. It is a randomly generated String of 10 chars length. You can see their implementation at cryptoUtils.newObjectId(). From the code we can conclude that they are not enforcing uniqueness.
https://github.com/ParsePlatform/parse-server/blob/master/src/cryptoUtils.js
Parse is probably using ids generated in Mongodb. They are not random and can be potentially predicted :
A BSON ObjectID is a 12-byte value
consisting of a 4-byte timestamp
(seconds since epoch), a 3-byte
machine id, a 2-byte process id, and a
3-byte counter
http://www.mongodb.org/display/DOCS/Object+IDs
I'm looking over Section 3.4 of RFC 3986 trying to understand what constitutes a valid URI query parameter key, but I'm not seeing a clear answer.
The reason I'm asking is because I'm writing a Ruby class that composes a URI with query parameters. When a new parameter is added I want to validate the key. Based on experience, it seems like the key will be invalid if it requires any escaping.
I should also say that I plan to validate the key. I'm not sure how to go about validating this data either, but I do know that in all cases I should escape this value.
Advice is appreciated. Advice in the context of how validation might already be possible through say a Ruby Gem would also be a plus.
I could well be wrong, but that spec seems to say that anything following '?' or '#' is valid as long. I wonder if you should be looking more at the spec for 'application/x-www-form-urlencoded' (ie. the key/value pairs we're all used to)?
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
This is the default content type. Forms submitted with this content
type must be encoded as follows:
Control names and values are escaped. Space characters are replaced by +', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by %HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
The control names/values are listed in the order they appear in the document. The name is separated from the value by =' and name/value pairs are separated from each other by &'.
I don't believe key=value is part of the RFC, it's a convention that has emerged. Wikipedia suggests this is an 'W3C recommendation'.
Seems like some good stuff to be found searching on the application/x-www-form-urlencoded content type.
http://www.w3.org/TR/REC-html40/interact/forms.html#form-data-set
I am reading the SCSI SPC4r22. In regards to ADDITIONAL LENGTH all revisions prior to spc3 have stated the following ("shall not be adjusted"):
From spc2r20.pdf:
"The ADDITIONAL LENGTH field shall specify the length in bytes of the parameters. If the ALLOCATION LENGTH of the CDB is too small to transfer all of the parameters, the ADDITIONAL LENGTH shall not be adjusted to reflect the truncation."
But I don't see that statement in SPC3 or SPC4. Has that been changed or am I missing the phrase? If I'm missing it, can someone please quote it?
It is just worded in a more general way:
"If the information being transferred to the Data-In Buffer includes fields containing counts of the number of bytes in some or all of the data, then the contents of these fields shall not
be altered to reflect the truncation"
I'm using SNMP4J to read info of devices with SNMP. Now I found some devices which represent the system name (OID iso.3.6.1.2.1.1.5.0) as a Hex-STRING instead of a STRING.
To show the system name I use the following code:
Variable var = response.getVariable(new OID(".1.3.6.1.2.1.1.5.0"));
System.out.println(var.toString());
Where response is a PDU object.
If the system name is represented as a STRING value, this goes as I expected. When it is represented as a Hex-STRING, it just prints the Hex value.
Example:
Take the name of the system as "SYSTEM NAME".
With STRING it prints "SYSTEM NAME".
With Hex-STRING it prints "53:59:53:54:45:4d:20:4e:41:4d:45"
Now with snmpwalk in command line I can just use the -Oa flag. This makes all Hex-STRING values show as STRING. Is it possible to use this flag in SNMP4J or is there a similar option?
I'm not sure where you're getting the term "Hex-STRING" from. SNMP does not define such a data type. I suggest you read through the relevant RFC documents, they are publicly available from IETF. The wikipedia article for SNMP (http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#References) has an excellent reference list, you can start with browsing the ones marked as "STD".
In SNMP, all strings are subtypes (or in a different word, "restrictions") of OCTET-STRING, a byte string of indeterminate length. It may contain any data, even non-printable stuff, representing a jpeg image or whatever.
Some textual-conventions have been defined, which restrict the data to some specific byte range, or length. A DisplayString is defined to only contain bytes from the NVT ASCII character set, so the user may trust it to be printable.
In fact, sysName is defined to be a DisplayString with a max length of 255 characters.
sysName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
Since a good SNMP manager is aware of RFC1213-MIB, which defines both sysName and DisplayString, the manager should assume that the data received is printable ASCII characters.
When you say "When it is represented as a Hex-STRING", what do you mean? "Represented" where, on the agent or in your Java code or when using the net-snmp "snmpwalk" command?
The var.toString() call should convert the contents of the variable into something that could be safely printed in a terminal, so it's possible that SNMP4j is converting any binary string to a hex string.
The documentation of elastic search states:
The index operation can be executed without specifying the id. In such
a case, an id will be generated automatically.
But it does not provide any information about the properties of the ids.
What is the length (minimun/maximum)?
my guess is 22.
Which characters are used in the id?
My guess is [-_A-Za-z0-9]
Can the properties of the generated ids change at any time (is that part of the API)?
Auto-generated ids are random base64-encoded UUIDs. The base64 algorithm is used in URL-safe mode hence - and _ characters might be present in ids.
Auto-generated ids by elasticsearch are exactly 20 characters length (not 22 characters) and encoded by url-safe base64 algorithm [-_A-Za-z0-9].
Read more in documentation: https://www.elastic.co/guide/en/elasticsearch/guide/master/index-doc.html#_autogenerating_ids