Re: [T2TRG] CoRAL Dictionaries and the side meeting yesterday

[Jim Schaad <[e-mail]>]

 

 

From: T2TRG <[e-mail]> On Behalf Of Klaus Hartke
Sent: Friday, November 22, 2019 9:22 PM
To: Jim Schaad <[e-mail]>
Cc: Klaus Hartke <[e-mail]>; [e-mail]
Subject: Re: [T2TRG] CoRAL Dictionaries and the side meeting yesterday

 

Hi Jim!

 

Jim Schaad wrote:

I am still having some problems with the way that you described how
dictionaries would work for CoRE apps with a single dictionary being used.

 

That may be because the current idea is not described well enough yet and because there is a problem with it. Let me try to explain. I’m very open to suggestions. 

 

My understanding of what you said is that:
1.  We would define a CoRE apps dictionary and pre-populate it with some of
the common items
2.  For each new CoRE app created (by the IETF?) the dictionary will be
extended by adding the new items to the dictionary (maybe the end, maybe
later)

 

Yes. The current idea is to have one dictionary that is shared by all CoRE apps defined by the IETF and that is maintained as an IANA registry. 

 

The assumption here seems to be that a CoRE app would never be extended with
new things.  As an example of what I mean consider the following:

*  Given the intense pressure from the ACE working group, the CoRE WG gets
it act together and releases a version 1 Pub-Sub server.  
* So a client and a server are released which use the dictionary for
compression and are both happy.
*  A version 2 of the Pub-Sub server gets released.  This adds some
vocabulary around wills.  The vocabulary is then added to the CoRE App
dictionary
*  The Pub-Sub server gets updated because it is a big box, but the client
does not because it is small
*  The client queries the Pub-Sub server and gets back some compression
points which it does not recognize.

 

This is exactly the current idea how you would evolve a CoRE app. 

 

What am I missing?

 

Assume for a moment that the V1 client could decompress the compression point. Then it still wouldn't recognize the wills-related vocabulary, because that’s a V2 feature. However, it can still make sense out of all the other vocabulary, so the V1 client is still interoperable with the V2 server. No problem here.. 

We’ve got a problem, though, when a V2 client understands the wills-related vocabulary, but doesn’t know the compression points for it (because they may have been added to the dictionary much later than the V2 specification was released). I don’t know how to solve that at the moment. 

 

Ok – So there are a couple of different things that potentially need to be addressed here:

 

1.	There needs to be a way to do some compression of CIRIs in the document.  I can think of multiple ways to do this either by using the dictionary or by using directives.  I think that having a base directive is going to be the best as the dictionary can compress the RHS of the base directive.  This allows for getting compression for items which are not in the current directory so creating or extending a vocabulary which is not yet in the global dictionary makes life better.
2.	It seems that there needs to be some way of being able to announce which version of a dictionary is understood by an entity.  While generally this would be from the client to the server, to del with the case you laid out, it could also be from the server to the client returned in an error message and then remembered by the client for a period of time.  After a bit of thought, the best way that I am currently seeing to deal with this would be to create a new directive which contains a dictionary version.  It might be that it should be able to have a pair of dictionary name, version number for dealing with non-IETF dictionaries.  What I would recommend for a version number would be a six digit value of the form YYYYMM and have an associated column in the IANA registry which contains the year and month that the row was added to the dictionary by IANA.  Having IANA assign this value allows for a well defined point where it occurs and would allow for early allocation if there was a rush to get some values into the dictionary.  Having point 1 would make it not quite as horrible if something is not in the registry as everything except the fragment could be compressed.

 

I think those two things plus a requirement for text would solve the issue.  The cases are:

1.	The client and server are on the same dictionary and vocabulary versions.  This is not a problem.
2.	The client and the server are on different dictionaries, but are on the same vocabulary version.  The versioning would allow for the two to agree on a dictionary version after one round trip.
3.	The client is on a higher vocabulary version than the server.  In this case the client may request features that the server does not support.  The application should specify what happens.  Note that this is a general issue for servers as they may not support all of the features of an application. 
4.	The server is on a higher vocabulary version than the client.  The server can process any requests, but might return answers that the client cannot process.  The normal response would be for the client to ignore things it does not understand, but again this is application defined behavior.  The answer may be different for different verbs.

 

Klaus