Subject: [Enum] The Matrix

From: Lawrence Conroy <[email-masked]>
Date: Thu, 30 May 2002 16:16:47 +0100

Hi Rudi, folks,

Welcome back to work and hope you dry out soon - Nice two-dimensional matrix!
At 3:59 am +0200 30/5/02, Brandner Rudolf wrote:
>To me, it looks like this is at least a two dimensional space. One 
>dimension is the protocols to be used (which then lead to the 
>associated URI), the other dimension is the function you can 
>perform. This gives you a matrix of combinations and two 
>possibilities of grouping. As an example (I am using  some high 
>level enumservices Lawrence proposed for this example and some 
>URIs), which is not exhaustive:
>
>FUNCTION
>--------
>:
>:
>--------+------+------+-------+---------+-------+------+--------
>talk    |  *   |  *   |  *    |  *      |       |      |
>--------+------+------+-------+---------+-------+------+--------
>srs     |      |  *   |       |         |       |      |
>--------+------+------+-------+---------+-------+------+--------
>deliver |  *   |      |       |  *      |       |  *   |
>--------+------+------+-------+---------+-------+------+--------
>         | tel: | sip: | h323: | mailto: | http: | ftp: |  ......  URI
>                                                                   ---
>
>The question you raise here is, which way is better for grouping? 
>Either proposal has implications on this, too.

Um...to use this, I suspect we need to define BOTH elements. Thus 
there will need to be:
*  a description of (say) the 'talk' function and the the URIs that 
might be used to provide it, PLUS
*  a description of (say) tel: operation with an explanation of how 
it works to provide each of the functions (with any special 
operational features that are specific to this protocol/function 
combination)

We could conflate each of these into a constellation of cross points 
(e.g. sdkTALK for an emumservice that is the product of the talk 
function and the tel: protocol/URI-scheme).
We could combine these points into a smaller number of RFCs.
For example, a single RFC could cover a column of the matrix.
Alternatively, a separate RFC could be provided for each row of the matrix.

I think that, with this conflation, either way there is bound to be a 
duplication of text.
Just choose an orientation.

The alternative I looked at with the strawman is to produce separate 
text for each column header and row header.
Thus there'd be a document describing the 'talk' function, another to 
describe the 'deliver' function, and separate documents each 
describing the 'tel:, 'h323:', and 'sip:' protocols/URI-schemes.
These could be combined by reference only. Thus for a talk service 
using tel:, look at the document describing 'talk', the separate 
document describing 'tel:', and that's it. For a talk service using 
h323:, look instead at the 'h323:' protocol document.

Any other offers?

OK, folks, place your bets;
- vertical,
- horizontal,
- exhaustive cloud of individual points, or
- individual column/row headers only (pick your own).
or...
- some scheme that is NOT in the above set of choices.

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

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