The rfc-editor says
"Obsoletes xxxx" refers to other RFCs that this one replaces.
"Updates xxxx" refers to other RFCs that this one merely updates but does not replace.
But this begs the question... why would an RFC update another RFC without replacing it?
Does "Updates" mean that some earlier information is contradicted in the older RFC, but other information is still standard? That seems odd.
The terms Updates and Obsoletes used to be defined by RFC 2223, but it is obsoleted by RFC 7322, which doesn't explicitly define these terms.
I think the earlier RFCs did a good job of defining these terms.
RFC 2223 — Obsoletes: 1543, 1111, 825
RFCs 2223, 1543, and 1111, which are all essential "Instructions to RFC Authors", defined these terms as their "Relation to other RFCs". RFC 825 was a very early version and did not define the terms.
RFC 2223 — 6. Relation to other RFCs
6. Relation to other RFCs
Sometimes an RFC adds information on a topic discussed in a previous
RFC or completely replaces an earlier RFC. There are two terms used
for these cases respectively, Updates and Obsoletes. A document that
obsoletes an earlier document can stand on its own. A document that
merely updates an earlier document cannot stand on its own; it is
something that must be added to or inserted into the previously
existing document, and has limited usefulness independently. The
terms Supercedes and Replaces are no longer used.
Updates
To be used as a reference from a new item that cannot be used
alone (i.e., one that supplements a previous document), to refer
to the previous document. The newer publication is a part that
will supplement or be added on to the existing document; e.g., an
addendum, or separate, extra information that is to be added to
the original document.
Obsoletes
To be used to refer to an earlier document that is replaced by
this document. This document contains either revised information,
or else all of the same information plus some new information,
however extensive or brief that new information is; i.e., this
document can be used alone, without reference to the older
document.
For example:
On the Assigned Numbers RFCs the term Obsoletes should be used
since the new document actually incorporate new information
(however brief) into the text of existing information and is
more up-to-date than the older document, and hence, replaces it
and makes it Obsoletes.
In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
the following may be used with early documents to point to later
documents.
Obsoleted-by
To be used to refer to the newer document(s) that replaces the
older document.
Updated-by
To be used to refer to the newer section(s) which are to be added
to the existing, still used, document.
RFC 7322 — Obsoletes: 2223
RFC 7322 doesn't define an RFCs "Relation to other RFCs" like earlier RFCs did.
I only find several mentions of the terms:
https://www.rfc-editor.org/rfc/rfc7322#section-4.1.4
4.1.4. Updates and Obsoletes
When an RFC obsoletes or updates a previously published RFC or RFCs,
this information is included in the document header. For example:
"Updates: nnnn" or "Updates: nnnn, ..., nnnn"
"Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"
If the document updates or obsoletes more than one document, numbers
will be listed in ascending order.
https://www.rfc-editor.org/rfc/rfc7322#section-4.1.
4.1. First-Page Header
Headers will follow the format described in "RFC Streams, Headers,
and Boilerplates" [RFC5741] and its successors. In addition, the
following conventions will apply.
RFC 5741 is mentioned, which is obsoleted by RFC 7841. It describes a header format for an RFCs "Relation to other RFCs", but it just refers back to RFC 7322.
RFC 7841 — header format for an RFCs "Relation to other RFCs"
...
[<RFC relation>:<RFC number[s]>] Some relations between RFCs in the
series are explicitly noted in the RFC header. For example, a new
RFC may update one or more earlier RFCs. Currently two
relationships are defined: "Updates" and "Obsoletes" [RFC7322].
Variants like "Obsoleted by" are also used (e.g, in [RFC5143]).
Other types of relationships may be defined by the RFC Editor and
may appear in future RFCs.
“Updates xxxx” just adds definitions to the existing RFC. The content of the existing RFC is not invalidated by the new RFC and is still needed to implement the protocol. This is used for example if there is no need to redefine the complete protocol but some clarifications are required.
“Obsoletes xxxx” is a complete redefinitio of a protocol. If not for other reasons, there is no need for you to read the obsoleted RFC to understand/correctly implement the protocol.
Related
When trying to validate a certain pdf's signature, I used the following code.
Validation results look good, apart from one thing: SignatureUtil#signatureCoversWholeDocument returns false.
It's obvious what that means. But I'm not sure about how to interpret this.
How can I determine which parts of the document aren't covered by the signature?
Can some evil guy change the document's content (if it's uncovered) while still keeping a valid signature?
In other words: how can I assure that this ain't nothing to be worried about?
You say that it's obvious what it means that SignatureUtil#signatureCoversWholeDocument returns false but just to be sure, first some backgrounds.
What Does It Mean When a PDF Signature Does Not Cover the Whole Document
At the moment they are applied, PDF signatures cover their respective whole document (except, of course, the embedded signature container itself, or more exactly a placeholder for it which might be a bit larger):
The ranges of signed bytes (from the file start to the placeholder start and from after the placeholder end to the file end) are specified in the signed part of the PDF.
Now the PDF format allows adding to a PDF document not only by re-building the whole document from scratch but alternatively also by adding changes after its end in so called incremental updates.
As the byte ranges signed by a PDF signature are specified in the document, this mechanism can even be used to add changes to a signed PDF without cryptographically breaking the signature.
This mechanism can be used for example to apply multiple PDF signatures to a document:
But the mechanism can also be used for a myriad other kinds of changes.
Allowed and Disallowed Changes
If one can add arbitrary changes to a signed PDF without breaking the signature cryptographically, one may wonder what the value of the signature is to start with.
Of course one can always extract and display/process the PDF revision a PDF signature covers (simply take the partial document from its start to the end of the second signed byte range). Thus, it is clear what the original PDF fully covered by the signature looked like. So a signed PDF can be considered a collection of logical documents, loosely based on one another: for each signature the document covered by it plus (if there are additional unsigned additions) the full document.
There actually are use cases where this makes sense, for example a document being created by a number of authors each signing of their respectively edited document version.
But the number of use cases in which that view is too diffuse is larger (or at least more important) still. In particular there are numerous use cases with multiple signatures in which one wants a PDF to represent a single logical document signed by multiple persons, at most with a few extra form fill-ins after the first signature.
To support such use cases the PDF specification defines a number of sets of allowed changes. Such a set can be selected by the first signature of the document. For details on these sets of allowed changes see this answer. In particular such allowed changes may encompass
adding or editing annotations,
supplying form field values, or
digitally signing.
Determining the Changes in a PDF and Checking Whether They Are Allowed in Practice
In the light of the previous section the question of the OP burns down to how one can determine the nature of the changes in incremental updates and how one can determine whether they are allowed or disallowed.
Determining which low-level objects in a PDF have changed actually is not that difficult to determine, see the PdfCompare and PdfRevisionCompare classes in this answer.
The real problem is checking whether these changes in low-level objects can be considered to only serve an allowed change as specified (or do not change the document semantically at all)!
Here even the "gold standard" (i.e. Adobe Acrobat) errs again and again, both in failing to recognize disallowed changes (see e.g. the "Attacks on PDF Certification" on pdf-insecurity.org for examples that meanwhile have been fixed) and in failing to recognize allowed changes (see e.g. here and here).
Essentially this is a very difficult task. And it is very unlikely you will find a good implementation in some open source project.
In particular iText 7 does not include such an analysis. If you want it, therefore, you'll have to implement it yourself.
You can simplify the task a bit if you expect the changes to be applied by a specific software. In that case you can analyze how (in terms of low-level objects) that software applies allowed changes and only accept such low-level changes. For example Adobe Acrobat is really good at recognizing allowed changes applied by Adobe software to PDFs created by Adobe software.
As per information available on web, PATCH is faster than PUT in REST API. But, if we're not checking before updating anything then PUT should be faster.
Definations:
The PATCH method is the correct choice if you're updating an existing resource.
PUT should only be used if you're replacing a resource in its entirety.
Specifically, the PUT method is described as follows in RFC 5789:
Several applications extending the Hypertext Transfer Protocol (HTTP)
require a feature to do partial resource modification. The existing
HTTP PUT method only allows a complete replacement of a document. This
proposal adds a new HTTP method, PATCH, to modify an existing HTTP
resource.
which is faster and why?
I don't think either of them is necessarily faster - PUT (defined by RFC 7231) and PATCH (defined by RFC 5789) are constraints on message semantics, not on implementation performance.
In cases where the representation of the resource is much larger than the HTTP headers, and the representation of the patch document is much smaller than the representation of the resource, the network latency might be a lot better than the additional time required to execute the patching.
Which is to say, I think you have to measure the latency profiles in your context, rather than expecting some universal ordering to apply.
Do you think that say 12 fields without foreign keys (I'm not sure if foreign keys even matter) constitute as a small object so that it'd make more sense to use PUT or would PATCH be fine (and what if 5 of those fields are foreign keys -- in case it matters)?
Foreign keys really shouldn't enter into the discussion at all; they are an implementation detail of the server; the client should be completely unaware of them.
is there a good way to use not hardcoded RFC destinations?
Right now our solution is to check which system is used and then assign the destination to a variable
IF cl_role EQ 'P'.
p_dest = 'ESW300'.
ELSE.
p_dest = 'EAW300'.
ENDIF.
which we use when calling our destination function.
CALL FUNCTION 'XYZ' DESTINATION p_dest
Is there a good way to not use the hardcoded destinations?
Thank you for the help!
RFC destinations are already an abstraction of the endpoint so I would not recommend to abstract it yet again. For that reason I would suggest using the same name across systems as a leading practice and not change them to be instance specific.
Otherwise I would suggest instead of hard-coding that you determine the RFC destination dynamically if you really want to use different RFC destination names across systems (I would not). If you look at some SAP standard programs they use specific format to determine the expected RFC destination name for example <hostname>_<systemname>_<system number> is used by SolMan but there are many examples if you look at the standard RFC destinations you can find.
I would also recommend as a best practice that any hard coded values never be populated inline as your example shows but in a header constant.
I realize you were probably only trying to focus on your question but for others reading this.
I saw every company creating its own custom table containing the RFC destinations (maintained differently in every SAP system by administrators; eventually it can be custom entries in the standard table TVARVC), but nobody published anything about it. Eventually this blog post but it's a very complex solution, only documented, but no code provided.
An easier (and adequate?) way is to create a Logical System (transaction code BD54) for every system, and assign a RFC destination (transaction code BD97).
In your program, do this kind of thing:
SELECT SINGLE rfcdest
FROM tblsysdest
WHERE logsys = 'CRM'
INTO #DATA(crm_system).
CALL FUNCTION 'RFC_PING' DESTINATION crm_system
EXCEPTIONS OTHERS = 1.
PS: prefer to abstract things, like creating a global class with one method GET_CRM_SYSTEM instead of hardcoding the SELECT in every program.
In appendix 1 of the UMLS license agreement, there is a listing of all sources within the current version of the UMLS Metathesaurus with an indication of any additional restrictions and notices that apply. Loosely speaking, it seems like you can generally have your way with the Metathesaurus data sources that fall within category-0 of the license, but things get more restrictive at categories above that.
For example (likely a bad example as I am not a lawyer), looking at section 12.2 of the main license section:
LICENSEE is prohibited from using the vocabulary source in operational
applications that create records or information containing data from
the vocabulary source. Use for data creation research or product
development is allowed.
My question then is: (since cTAKES already has my UMLS credentials) is there any way to tell when doing a certain action with cTAKES is going to instruct it use/access data from the Metathesaurus that have a category > 0 (eg. some popup warning or header comment in the binary files)? Thanks
** The reason I'm interested is because: suppose that a certain ctakes process uses a category-2 data source to do something on some input that populates data into some XMI output (I don't know much about ctakes' full implementation, but for sake of arg. lets assume this is true) that gets post-processed and stored as some report for an organization. It would seem that the organization has violated the category-2 restriction inadvertently (since they were never warned about the underlying data being used to generate the outputs). I may be grossly misunderstanding something here, so please let me know if this is the case.
I am posing this use case as a reason to enable support for the CDATA section of XML documents on SQL Server, in response to the opinion of Michael Rys.
He states that
"There is no semantic difference in the data that you store."
I am a software controls engineer where we use a supervised distributed system, we generally have a windows based server and database for supervisory functions as well as high speed machine control applications. We use any number of PLCs to compose our distributed control system, and we keep a copy of the PLC program on the server. The PLC program is L5X format that calls for the CDATA section per specification (see page 40 for more info).
The CDATA section is used for component descriptions due to invalid XML characters being present in some of them and the need to preserve them:
"Component descriptions are brought into the project without being processed by
the XML parser for markup language. The description text is contained in a
CDATA element, a standard in the XML specification. A CDATA element
begins with the character sequence <![CDATA[ and ends with the character
sequence ]]>. None of the text within the CDATA element is interpreted by the
XML parser. The CDATA element preserves formatting so there is no need to use
control characters to enter formatted descriptions."
Here, I think at least, is an entirely valid reason for the existence and use of the CDATA section - in contrast the the opinion of Microsoft.
Buggy tools.
You may find it more or less convenient, but the only technical reasons is if you have buggy tools that don't follow the XML rules in some way.
The CDATA section is used for component descriptions due to invalid XML characters being present in some of them and the need to preserve them.
Either you mean characters that are invalid in XML unescaped, in which case they could also be escaped, or you mean characters that are not valid in XML at all, in which case they are not valid CDATA sections. In the first case if your tools can't work with that, they are buggy. In the second case if your tools require you to work with that, they are buggy. Either way this is in the buggy tools category.
The general consensus in the XML community is that the following three forms are semantically equivalent:
<x>±</x>
<x>±</x>
<x><![CDATA[±]]></x>
and that XML processing software therefore does not need to preserve the distinction between them. This is why entity references (or numeric character references) and CDATA sections are not part of the data model used by XPath, XSLT, and XQuery (known as XDM).
Unfortunately the XML specification itself does not define a data model and is rather weak on saying which constructs are information-bearing and which are not, so there will always be people coming up with arguments like this, just as there will be people arguing that the order of attributes should be preserved.