File: rfc2656.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (507 lines) | stat: -rw-r--r-- 17,409 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507






Network Working Group                                           T. Hardie
Request For Comments: 2656                                        Equinix
Category: Experimental                                        August 1999

            Registration Procedures for SOIF Template Types

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The Summary Object Interchange Format [Ref. 1] was first defined by
   the Harvest Project [Ref 2.] in January 1994.  SOIF was derived from
   a combination of the Internet Anonymous FTP Archives IETF Working
   Group (IAFA) templates [Ref 3.] and the BibTeX bibliography format
   [Ref 4.].  The combination was originally noted for its advantages of
   providing a convenient and intuitive way for delimiting objects
   within a stream, and setting apart the URL for easy object access or
   invocation, while still preserving compatibility with IAFA templates.

   SOIF uses named template types to indicate the attributes which may
   be contained within a particular summary object.  Within the context
   of a single application, private agreement on the definition of
   template types has been adequate.  As SOIF objects are moved among
   applications, however, the need for standard, well-specified, and
   easily identifiable template types increases.  This need is
   particularly intense in the context of query referral, where
   knowledge of an attribute's definition and the allowed data types for
   specific values is crucial.  For a discussion of this in the context
   of the Common Indexing Protocol, see [Ref. 1].

   The registration procedure described in this document is specific to
   SOIF template types.  There is ongoing work within the IETF to
   specify a more generic schema registration facility[Ref. 5].  It is
   not yet clear whether the results of that work will encompass the
   ability to register entities like SOIF template types.  If it does
   so, the registration of SOIF template types may be shifted to that
   method and registry.  Should that occur, appropriate pointers will be
   created in cooperation with the Registrar to ensure that no
   registrations are lost.



Hardie                        Experimental                      [Page 1]

RFC 2656            Registration Procedures for SOIF         August 1999


1.  Registrar

   The initial registrar of SOIF template types will be the Internet
   Assigned Numbers Authority (IANA).

2.  Defining Template Types

   Each SOIF object is composed of 3 fundamental components: a template
   type IDENTIFIER, a URL, and zero or more ATTRIBUTE-VALUE pairs.  See
   [Ref 1.] for the formal grammar of SOIF and a description of how
   these components interrelate.  As part of the registration process,
   registrants must: propose a template type IDENTIFER; list the
   ATTRIBUTEs which the template may contain; identify whether each
   ATTRIBUTE is mandatory or optional; and specifiy the data type and
   encoding appropriate for the VALUEs associated with each ATTRIBUTE.

2.1 The template type IDENTIFIER

   The IDENTIFIER for the template type is assigned at registration
   based on a proposal from the registrant.  It is, however, at the sole
   discretion of the registrars to assign specific IDENTIFIERS.  While
   they will normally assign the IDENTIFIERs proposed by registrants,
   they may choose to modify a proposed IDENTIFIER to avoid conflict
   with other existing or proposed template types.

   Because of the pre-installed base of servers using privately agreed
   upon template types, applications using SOIF need to be able to
   ascertain whether a referenced template type has been registered.  In
   order to accomplish this, all template type IDENTIFIERS for template
   types registered with the IANA will begin with the ASCII string
   "IANA-".  An IANA-registered template type based on the GILS
   specification, for example, might be registered as "IANA-GILS".
   Should other registrars emerge over time, similar strings must be
   established and used to compose template type IDENTIFIERS which they
   assign.

2.2 The URL

   The URL associated with a particular summary object is determined by
   the application generating the object.  Applications must generate
   valid URLs according to the rules of [Ref 6.], but there is no
   restriction on what sorts of URLs may be associated with particular
   template types.  The use of a particular template type indicates the
   type of information contained in the summary object, not how the
   inital resource being summarized was accessed.  This aspect of SOIF
   summary objects is therefor not subject to registration.





Hardie                        Experimental                      [Page 2]

RFC 2656            Registration Procedures for SOIF         August 1999


2.3 ATTRIBUTES

   Where an ATTRIBUTE associated with a proposed template type exactly
   matches an ATTRIBUTE previously defined in a registered template
   type, the proposed ATTRIBUTE should be defined by reference to the
   existing, registered ATTRIBUTE.  This allows query referral meshes to
   easily map queries against ATTRIBUTEs derived from different template
   types and provides an easy method for extending or restricting an
   existing template type to match an application's particular needs.
   In such cases, the ATTRIBUTE for the newly registered template type
   will have the same name, description, and allowed values as the
   ATTRIBUTE in the existing registered template type.

   Where no existing ATTRIBUTE may be referenced, registrants must
   specify each ATTRIBUTE's name, description, and allowed values.

2.3.1 ATTRIBUTE names

   To handle multiple VALUEs for the same ATTRIBUTE, SOIF uses a naming
   convention, appending a hyphen and a positive integer to the base
   ATTRIBUTE name to create a unique ATTRIBUTE IDENTIFIER.  For example,
   the ATTRIBUTE IDENTIFIERs "Publisher-1", "Publisher-2", and
   "Publisher-3" can be used to associate three VALUEs with the
   ATTRIBUTE named "Publisher".  In order to provide for the unimpeded
   operation of this convention, ATTRIBUTE names may not terminate with
   a hyphen followed by an integer.  ATTRIBUTE names are otherwise
   restricted only by the grammar defined in [Ref. 1].

   In general, registrants will probably wish to propose ATTRIBUTE names
   which are short, mnemonic, and intuitively associated with the
   characterstic that the ATTRIBUTE describes.  While these may be
   generally laudable goals, it must be remembered that the application
   interface need not present the raw ATTRIBUTE name to the end user;
   indeed, in situations where the end user's language does not use the
   ASCII character set, the interface must map the ATTRIBUTE name to an
   appropriate local representation.  Since ATTRIBUTE definitions are
   provided as part of the registration process, registrants should
   avoid attempting to overload the ATTRIBUTE name with information
   which belongs in the description.

2.3.2  ATTRIBUTE descriptions

   ATTRIBUTE descriptions for ATTRIBUTEs registered with the IANA must
   be in English, though mappings to other languages may be proposed as
   part of the ATTRIBUTE description.  ATTRIBUTE descriptions should
   propose clear criteria for establishing whether an object posseses a
   particular ATTRIBUTE.  Descriptions should also include at least two
   examples of how each attribute relates to an object being summarized,



Hardie                        Experimental                      [Page 3]

RFC 2656            Registration Procedures for SOIF         August 1999


   using, where possible, objects which are broadly available to a wide
   variety of audiences.  If several ATTRIBUTEs within a template type
   inter-relate, the descriptions of each may reference the others; care
   must be taken, however, that the resulting descriptions are not
   circular. Where fully realized specifications of the ATTRIBUTEs have
   been created in other contexts, the salient text from those
   descriptions should be quoted and appropriate references cited.

2.3.3 Required and Optional Attributes

   Each ATTRIBUTE registered for a template type must be marked either
   required or optional.  Note that marking an ATTRIBUTE required does
   not imply that it may not have a null value; it implies only that it
   must appear in all templates of that registered template type.

2.4 VALUES

   For each ATTRIBUTE, the registrant must specify the data format and,
   if appropriate, the language, character set, and encoding.  Where
   possible, the registrant should include references to a precise and
   openly available specification of the format.  The registrant must
   also specify the appropriate matching semantics for the ATTRIBUTE if
   these are not strictly implied by the data format and encoding.  The
   registrant must also note whether null values are permitted.

3. Versioning

   Creating a revision of a template type is functionally similar to
   creating a new template type.  A Registrant may propose as a name any
   derivative allowed under the rules of section 4.1 and [Ref. 1] to the
   new template type.  ATTRIBUTEs retained across versions without
   modification should be referenced as described in section 4.3.
   Modified ATTRIBUTEs must be described as if new.  A registrant may
   note a relationship between a proposed template type and an existing
   template type as part of the registration process.  The following
   three relationships are currently defined:

   Successor: for proposed template types intended to replace an
   existing template type.

   Variant: for proposed template types whose ATTRIBUTEs are either a
   superset or a subset of an existing template type.

   Alternate: for proposed template types which share a large number of
   ATTRIBUTEs with an existing template type but whose ATTRIBUTEs do not
   form a strict superset or subset of an existing template type.





Hardie                        Experimental                      [Page 4]

RFC 2656            Registration Procedures for SOIF         August 1999


   Note that there may be relationships between ATTRIBUTEs of different
   template types without there being a named relationship between the
   template types themselves.

4. Security

   SOIF template types which are intended for applications which will
   pass summary objects over the global Internet should contain
   authentication ATTRIBUTEs.  SOIF summary objects lacking
   authentication ATTRIBUTEs must be treated as unreliable indicators of
   the referenced resource's content and should only be used where other
   aspects of the environment provide sufficient security to prevent
   spoofing.  Given, however, that particular template types may be
   intended for environments with such security, there is no requirement
   that registered template types contain authentication ATTRIBUTEs.
   The application developer must select or propose a template type
   appropriate for the intended appliation environment; if none is
   available with suitable authentication ATTRIBUTEs, the provisions of
   section 4.3 make it easy for the developer to propose an extension to
   an existing template type with the appropriate authentication
   ATTRIBUTEs.

5.  References

   [1]  Hardie, T., Bowman, M., Hardy, D., Schwartz, M. and D. Wessels,
        "CIP Index Object Format for SOIF Objects", RFC 2655, August
        1999.

   [2]  The Harvest Information Discovery and Access System:
        <URL:http://harvest.transarc.com/>.

   [3]  D. Beckett, IAFA Templates in Use as Internet Metadata, 4th
        Int'l WWW Conference, December 1995,
        <URL:http://www.hensa.ac.uk/tools/www/iafatools/>

   [4]  L. Lamport, LaTeX: A Document Preparation System, Addison-
        Wesley, Reading, Mass., 1986.

   [5]  IETF Schema Registration Working Group.
        <URL:http://www.ietf.org/html.charters/wg.dir#Applications_Area>

   [6]  Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
        Locators (URL)", RFC 1738, December 1994.








Hardie                        Experimental                      [Page 5]

RFC 2656            Registration Procedures for SOIF         August 1999


6.  Author's Address

   Ted Hardie
   Equinix
   901 Marshall Street
   Redwood City, CA 94063 USA

   EMail: hardie@equinix.com











































Hardie                        Experimental                      [Page 6]

RFC 2656            Registration Procedures for SOIF         August 1999


Appendix A.

   An Example Registration Form

   1. Registrant's Name ________________________________________

   2. Registrant's Organization ________________________________

   3. Registrant's email address _______________________________

   4. Registrant's postal address ______________________________
                                  ______________________________
                                  ______________________________
                                  ______________________________

   5. Registrant's telephone number ____________________________

   6. Proposed Template Type IDENTIFIER: IANA-__________________

   7. If this Template Type relates to an existing Template Type
   list the Template Type(s) and the relationship:

   Template Type ___________________ Relationship ______________

   8. For each ATTRIBUTE in this Template type, provide the
   following information:

   a) NAME _____________________________________________________

   b) Reference Template Type __________________________________

   If there is no registered Template Type which has already
   specified this attribute, provide the following information:

   c) ATTRIBUTE Description ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________
                            ____________________________________



Hardie                        Experimental                      [Page 7]

RFC 2656            Registration Procedures for SOIF         August 1999


   d) Required [] or Optional []?

   e) Data Type and ecoding for this VALUE _____________________
                                           _____________________
                                           _____________________

   f) If a specific language and character set are expected, list
   them here ___________________________________________________

   g) Is a null value permitted? Yes [] No []









































Hardie                        Experimental                      [Page 8]

RFC 2656            Registration Procedures for SOIF         August 1999


7.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hardie                        Experimental                      [Page 9]