Subject: RE: [NSIS] common signalling application functions (was RE: Tenta tive Interi m Meeting schedule)

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 29 Apr 2004 11:12:19 +0200

Robert,

|Here is a modified approach:
|- it should be possible to use a single object definition
|  in multiple applications
|- the implication is that there should be a single identifier
|  space for NSLP objects (one IANA registry for the T values 
|  in the TLV format)

That's a good idea.

|- extensibility rules about mandatoriness/optionality will
|  probably have to be common between different applications
|  and encoded separately from the object types

This allows to combine different objects as required by a 
specific NSLP application, right? Then it is a good idea too.

|where should this sort of structural information be stated
|where and how should the common objects be defined; and which 
|people are working on defining them.

Two approaches come to my mind:
- a single toolbox doc containing all basic rules, data 
  formats and parameters ever specified for any NSLP.
- NSLP application specs referring to toolbox contents.

or
- a spec of basic rules and data formats.
- NSLPs defining parameters and cross-referencing if one 
  re-uses a parameter of another.

The first would be the cleaner approach, but it creates a 
lot of ongoing maintenance acitivty. The latter better suits 
to WG's of limited lifetime. It however requires some 
mechanism to prevent repeated specification of the same 
feature. If a simple an reliable mechanism to prevent this 
can be designed, I'd tend to the second approach. 

Regards, Rüdiger

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis