← Back to branch summary

~ubuntu-dev/ubuntu/lucid/dovecot/lucid-201002101901

« back to all changes in this revision

Viewing changes to libsieve/doc/rfc/environment.rfc5183.txt

  • Committer: Chuck Short
  • Date: 2010-01-21 20:21:25 UTC
  • mfrom: (4.1.11 squeeze)
  • Revision ID: zulcss@ubuntu.com-20100121202125-pme73o491kfwj5nc
http://bugs.debian.org/493803
http://bugs.debian.org/523810
http://bugs.debian.org/545582
http://bugs.debian.org/549944
http://bugs.debian.org/554306
http://bugs.debian.org/554710
http://bugs.debian.org/557601
http://bugs.debian.org/558040
https://launchpad.net/bugs/164837
https://launchpad.net/bugs/254721
https://launchpad.net/bugs/329878
* Merge from debian testing, remaining changes:
  + Add new binary pkg dovecot-postfix that integrates postfix and dovecot
    automatically: (LP: #164837)
  + debian/control:
    - add new binary with short description
    - set Architecture all for dovecot-postfix (LP: #329878)
  + debian/dovecot-postfix.postinst:
    - create initial certificate symlinks to snakeoil.
    - set up postfix with postconf to:
      - use Maildir/ as the default mailbox.
      - use dovecot as the sasl authentication server.
      - use dovecot LDA (deliver).
      - use tls for smtp{d} services.
    - fix certificates paths in postfix' main.cf
    - add reject_unauth_destination to postfix' recipient restrictions
    - add reject_unknown_sender_domain to postfix' sender restriction
    - rename configuration name on remove, delete on purge
    - restart dovecot after linking certificates
    - handle use case when postfix is unconfigurated
  + debian/dovecot-postfix.dirs: create backup directory for postfix's config
    configuration
  + restart postfix and dovecot.
  + debian/dovecot-postfix.postrm:
    - remove all dovecot related configuration from postfix.
    - restart postfix and dovecot.
  + debian/dovecot-common.init:
    - check if /etc/dovecot/dovecot-postfix.conf exists and use it
      as the configuration file if so.
  + debian/patches/warning-ubuntu-postfix.dpatch
    - add warning about dovecot-postfix.conf in dovecot default
      configuration file
  + debian/patches/dovecot-postfix.conf.diff:
    - Ubuntu server custom changes to the default dovecot configuration for
      better interfation with postfix.
    - enable sieve plugin.
    - Ubuntu server custom changes to the default dovecot configuration for
      better integration with postfix:
      - enable imap, pop3, imaps, pop3s and managesieve by default.
      - enable dovecot LDA (deliver).
      - enable SASL auth socket in postfix private directory
   + debian/rules:
     - copy, patch and install dovecot-postfix.conf in /etc/dovecot/.
     - build architecure independent packages too
   + Use Snakeoil SSL certificates by default.
     - debian/control: Depend on ssl-cert.
     - debian/patches/ssl-cert-snakeoil.dpatch: Change default SSL cert
       paths to snakeoil.
     - debian/dovecot-common.postinst: Relax grep for SSL_* a bit.
   + Add autopkgtest to debian/tests/*.
   + Fast TearDown: Update the lsb init header to not stop in level 6.
   + Add ufw integration:
     - Created debian/dovecot-common.ufw.profile.
     - debian/rules: install profile.
     - debian/control: suggest ufw.
   + debian/{control,rules}: enable PIE hardening.
   + dovecot-imapd, dovecot-pop3: Replaces dovecot-common (<< 1:1.1). (LP: #254721)
   + debian/control: Update Vcs-* headers.
   + Add SMTP-AUTH support for Outlook (login auth mechanism)
* New upstream release.
* debian/patches/gold-fix.patch: Removed. Fixed upstream.
* Moved libexec to lib corrections in dovecot-managesieve.patch and
  dovecot-managesieve-dist.patch to dovecot-example.patch
* debian/patches/dovecot-mboxlocking.patch: Regenerated to avoid FTBFS
  when quilt isn't installed.
* debian/patches/quota-mountpoint.patch: Removed. Not needed anymore.
* debian/patches/dovecot-quota.patch: Removed. Quotas aren't properly
  enabled unless mail_plugins = quota imap_quota.
* debian/patches/gold-fix.patch: Fixed configure script to build even
  with binutils-gold or --no-add-needed linker flag (Closes: #554306)
* debian/dovecot-common.init: fixed LSB headers. Thanks to Pascal Volk.
  (Closes: #558040)
* debian/changelog: added CVE references to previous changelog entry.
* debian/rules: checked up the build system. It's not fragile anymore.
  (Closes: 493803)
* debian/dovecot-common.postinst: Now invoking dpkg-reconfigure
  on dovecot-common is enough to generate new certificates
  if the previous ones were removed. (Closes: #545582)
* debian/rules: No longer install convert-tool in /usr/bin.
  It isn't an user utility and it should stay in /usr/lib/dovecot
  like all other similar tool.
* New upstream release. (Closes: #557601)
* [SECURITY] Fixes local information disclosure and denial of service.
  (see: http://www.dovecot.org/list/dovecot-news/2009-November/000143.html
  and CVE-2009-3897)
* Added myself to uploaders.
* Switched to the new source format "3.0 (quilt)":
  - removed dpatch from build-depends
  - removed debian/README.source because now we use only standard
    dpkg features
  - regenerated all patches
* Prepared to switch to multi-origin source:
  - recreated dovecot-libsieve.patch and dovecot-managesieve-dist.patch
    starting from the upstream tarball
  - removed all autotools related build-depends and build-conflict
  - renamed dovecot-libsieve and dovecot-managesieve directories
    to libsieve and managesieve.
* debian/rules: Moved the configuration of libsieve and managesieve from
  the build phase to the configuration phase
* Added dovecot-dbg package  with debugging symbols.  Thanks Stephan Bosch.
  (Closes: #554710)
* Fixed some stray libexec'isms in the default configuration.
* New upstream release.
* debian/dovecot-common.init:
  - use $CONF when starting the daemon. (Closes: #549944)
  - always output start/stop messages. (Closes: #523810)

Show diffs side-by-side

added added

removed removed

Lines of Context:
libsieve/doc/rfc/environment.rfc5183.txt
 
1
 
 
2
 
 
3
 
 
4
 
 
5
 
 
6
 
 
7
Network Working Group                                           N. Freed
 
8
Request for Comments: 5183                              Sun Microsystems
 
9
Category: Standards Track                                       May 2008
 
10
 
 
11
 
 
12
              Sieve Email Filtering: Environment Extension
 
13
 
 
14
Status of This Memo
 
15
 
 
16
   This document specifies an Internet standards track protocol for the
 
17
   Internet community, and requests discussion and suggestions for
 
18
   improvements.  Please refer to the current edition of the "Internet
 
19
   Official Protocol Standards" (STD 1) for the standardization state
 
20
   and status of this protocol.  Distribution of this memo is unlimited.
 
21
 
 
22
Abstract
 
23
 
 
24
   This document describes the "environment" extension to the Sieve
 
25
   email filtering language.  The "environment" extension gives a Sieve
 
26
   script access to information about the Sieve interpreter itself,
 
27
   where it is running, and about any transport connection currently
 
28
   involved in transferring the message.
 
29
 
 
30
1.  Introduction
 
31
 
 
32
   Sieve [RFC5228] is a language for filtering email messages at or
 
33
   around the time of final delivery.  It is designed to be
 
34
   implementable on either a mail client or mail server.  It is suitable
 
35
   for running on a mail server where users may not be allowed to
 
36
   execute arbitrary programs, such as on black box Internet Message
 
37
   Access Protocol [RFC3501] servers, as it has no user-controlled loops
 
38
   or the ability to run external programs.
 
39
 
 
40
   Although Sieve is intended to be independent of access protocol, mail
 
41
   architecture, and operating system, in some cases it is useful to
 
42
   allow scripts to access information about their execution context.
 
43
   The "environment" extension provides a new environment test that can
 
44
   be used to implement scripts that behave differently when moved from
 
45
   one system to another, when messages arrive from different remote
 
46
   sources or when otherwise operated in different contexts.
 
47
 
 
48
2.  Conventions Used in This Document
 
49
 
 
50
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 
51
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 
52
   document are to be interpreted as described in [RFC2119].
 
53
 
 
54
 
 
55
 
 
56
 
 
57
 
 
58
Freed                       Standards Track                     [Page 1]
 
59
 
 
60
RFC 5183              Sieve Environment Extension               May 2008
 
61
 
 
62
 
 
63
   The terms used to describe the various components of the Sieve
 
64
   language are taken from Section 1.1 of [RFC5228].
 
65
 
 
66
   This document refers to the ABNF productions IPv4-address-literal,
 
67
   IPv6-address-literal, and General-address-literal defined in Section
 
68
   4.1.3 of [RFC2821].
 
69
 
 
70
   The location item makes use of standard terms for email service
 
71
   components.  Additional information and background on these terms can
 
72
   be found in [EMAIL-ARCH].
 
73
 
 
74
3.  Capability Identifiers
 
75
 
 
76
   The capability string associated with the extension defined in this
 
77
   document is "environment".
 
78
 
 
79
4.  Environment Test
 
80
 
 
81
   Usage:   environment [COMPARATOR] [MATCH-TYPE]
 
82
                        <name: string>
 
83
                        <key-list: string-list>
 
84
 
 
85
   The environment test retrieves the item of environment information
 
86
   specified by the name string and matches it to the values specified
 
87
   in the key-list argument.  The test succeeds if a match occurs.  The
 
88
   type of match defaults to ":is" and the default comparator is
 
89
   "i;ascii-casemap".
 
90
 
 
91
   The current message is not a direct source of information for the
 
92
   environment test; the item of information specified by the name
 
93
   string is extracted from the script's operating environment and the
 
94
   key-list argument comes from the script.
 
95
 
 
96
   The environment test MUST fail unconditionally if the specified
 
97
   information item does not exist.  A script MUST NOT fail with an
 
98
   error if the item does not exist.  This allows scripts to be written
 
99
   that handle nonexistent items gracefully.  In particular, the test:
 
100
 
 
101
     if environment :contains "item" "" { ... }
 
102
 
 
103
   only succeeds if "item" is known to the implementation, and always
 
104
   succeeds if it is.
 
105
 
 
106
   The "relational" extension [RFC5231] adds a match type called
 
107
   ":count".  The count of an environment test is 0 if the environment
 
108
   information returned is the empty string, or 1 otherwise.
 
109
 
 
110
 
 
111
 
 
112
 
 
113
 
 
114
Freed                       Standards Track                     [Page 2]
 
115
 
 
116
RFC 5183              Sieve Environment Extension               May 2008
 
117
 
 
118
 
 
119
   Environment items can be standardized or vendor-defined.  An IANA
 
120
   registry is defined for both types of items.  Extensions designed for
 
121
   interoperable use SHOULD be defined in standards track or
 
122
   experimental RFCs.
 
123
 
 
124
4.1.  Initial Standard Environment Items
 
125
 
 
126
   The initial set of standardized environment items is as follows:
 
127
 
 
128
    "domain"  => The primary DNS domain associated with the Sieve
 
129
                 execution context, usually but not always a proper
 
130
                 suffix of the host name.
 
131
 
 
132
    "host"    => The fully-qualified domain name of the host where
 
133
                 the Sieve script is executing.
 
134
 
 
135
    "location"
 
136
              => Sieve evaluation can be performed at various
 
137
                 different points as messages are processed.  This item
 
138
                 provides additional information about the type of
 
139
                 service that is evaluating the script.  Possible values
 
140
                 are "MTA", meaning the Sieve is being evaluated by a
 
141
                 Message Transfer Agent, "MDA", meaning evaluation is
 
142
                 being performed by a Mail Delivery Agent, "MUA",
 
143
                 meaning evaluation is being performed by a Mail User
 
144
                 Agent, and "MS", meaning evaluation is being performed
 
145
                 by a Message Store.  Additional information and
 
146
                 background on these terms can be found in
 
147
                 [EMAIL-ARCH].
 
148
 
 
149
    "name"    => The product name associated with the Sieve interpreter.
 
150
 
 
151
    "phase"   => The point relative to final delivery where the
 
152
                 Sieve script is being evaluated.  Possible values are
 
153
                 "pre", "during", and "post", referring respectively to
 
154
                 processing before, during, and after final delivery
 
155
                 has taken place.
 
156
 
 
157
    "remote-host"
 
158
              => Host name of remote SMTP/LMTP/Submission client
 
159
                 expressed as a Fully Qualified Domain Name (FQDN),
 
160
                 if applicable and available.  The empty string will be
 
161
                 returned if for some reason this information cannot be
 
162
                 obtained for the current client.
 
163
 
 
164
 
 
165
 
 
166
 
 
167
 
 
168
 
 
169
 
 
170
Freed                       Standards Track                     [Page 3]
 
171
 
 
172
RFC 5183              Sieve Environment Extension               May 2008
 
173
 
 
174
 
 
175
    "remote-ip"
 
176
              => IP address of remote SMTP/LMTP/Submission client, if
 
177
                 applicable and available.  IPv4, IPv6, and other types
 
178
                 of addresses are respectively represented in the
 
179
                 formats defined by the IPv4-address-literal,
 
180
                 IPv6-address-literal, and General-address-literal
 
181
                 productions defined in Section 4.1.3 of [RFC2821].
 
182
 
 
183
    "version" => The product version associated with the Sieve
 
184
                 interpreter.  The meaning of the product version string
 
185
                 is product-specific and should always be considered
 
186
                 in the context of the product name given by the
 
187
                 "name" item.
 
188
 
 
189
   Implementations SHOULD support as many of the items on this initial
 
190
   list as possible.  Additional standardized items can only be defined
 
191
   in standards-track or experimental RFCs.
 
192
 
 
193
4.2.  Vendor-defined Environment Items
 
194
 
 
195
   Environment item names beginning with "vnd." represent vendor-defined
 
196
   extensions.  Such extensions are not defined by Internet standards or
 
197
   RFCs, but are still registered with IANA in order to prevent
 
198
   conflicts.
 
199
 
 
200
4.3.  IANA Registration of Environment Items
 
201
 
 
202
   A registry of environment items is provided by IANA.  Item names may
 
203
   be registered on a first-come, first-served basis.
 
204
 
 
205
   Groups of items defined in a standards track or experimental RFC MAY
 
206
   choose to use a common name prefix of the form "name.", where "name"
 
207
   is a string that identifies the group of related items.
 
208
 
 
209
   Items not defined in a standards track or experimental RFC MUST have
 
210
   a name that begins with the "vnd." prefix, and this prefix is
 
211
   followed by the name of the vendor or product, such as
 
212
   "vnd.acme.rocket-sled-status".
 
213
 
 
214
 
 
215
 
 
216
 
 
217
 
 
218
 
 
219
 
 
220
 
 
221
 
 
222
 
 
223
 
 
224
 
 
225
 
 
226
Freed                       Standards Track                     [Page 4]
 
227
 
 
228
RFC 5183              Sieve Environment Extension               May 2008
 
229
 
 
230
 
 
231
4.3.1.  Template for Environment Registrations
 
232
 
 
233
   The following template is to be used for registering new Sieve
 
234
   environment item names with IANA.
 
235
 
 
236
      To: iana@iana.org
 
237
      Subject: Registration of new Sieve environment item
 
238
 
 
239
      Item name: [the string for use in the 'environment' test]
 
240
      Description:     [a brief description of the semantics of the
 
241
                        value the item returns]
 
242
 
 
243
      RFC number:      [for extensions published as RFCs]
 
244
      Contact address: [email and/or physical address to contact for
 
245
                        additional information]
 
246
 
 
247
   Multiple items and descriptions MAY be specified in a single
 
248
   registration request.  Both standardized and vendor-defined items use
 
249
   this form.
 
250
 
 
251
5.  Security Considerations
 
252
 
 
253
   The environment extension may be used to obtain information about the
 
254
   system the Sieve implementation is running on.  This information in
 
255
   turn may reveal details about service provider or enterprise
 
256
   infrastructure.
 
257
 
 
258
   An implementation can use any technique to determine the remote-host
 
259
   environment item defined in this specification, and the
 
260
   trustworthiness of the result will vary.  One common method will be
 
261
   to perform a PTR DNS lookup on the client IP address.  This
 
262
   information may come from an untrusted source.  For example, the
 
263
   test:
 
264
 
 
265
     if environment :matches "remote-host" "*.example.com" { ... }
 
266
 
 
267
   is not a good way to test whether the message came from "outside"
 
268
   because anyone who can create a PTR record can create one that refers
 
269
   to whatever domain they choose.
 
270
 
 
271
   All of the security considerations given in the base Sieve
 
272
   specification also apply to this extension.
 
273
 
 
274
 
 
275
 
 
276
 
 
277
 
 
278
 
 
279
 
 
280
 
 
281
 
 
282
Freed                       Standards Track                     [Page 5]
 
283
 
 
284
RFC 5183              Sieve Environment Extension               May 2008
 
285
 
 
286
 
 
287
6.  IANA Considerations
 
288
 
 
289
   The following template specifies the IANA registration of the Sieve
 
290
   extension specified in this document:
 
291
 
 
292
      To: iana@iana.org
 
293
      Subject: Registration of new Sieve extension
 
294
 
 
295
      Capability name: environment
 
296
      Description:     The "environment" extension provides a new
 
297
                       environment test that can be used to implement
 
298
                       scripts that behave differently when moved
 
299
                       from one system to another or otherwise
 
300
                       operated in different contexts.
 
301
      RFC number:      RFC 5183
 
302
      Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
 
303
 
 
304
   This specification also defines a new IANA registry for Sieve
 
305
   environment item names.  The specifics of this registry are given in
 
306
   Section 4.3.  The initial contents of the registry are given in the
 
307
   following section.
 
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
Freed                       Standards Track                     [Page 6]
 
339
 
 
340
RFC 5183              Sieve Environment Extension               May 2008
 
341
 
 
342
 
 
343
6.1.  Initial Environment Item Registrations
 
344
 
 
345
   The following template specifies the initial IANA registrations for
 
346
   the environment items defined in this document:
 
347
 
 
348
      To: iana@iana.org
 
349
      Subject: Registration of new Sieve environment items
 
350
 
 
351
      Capability name: domain
 
352
      Description:     The primary DNS domain associated with the Sieve
 
353
                       execution context, usually but not always a
 
354
                       proper suffix of the host name.
 
355
 
 
356
      Capability name: host
 
357
      Description:     The fully-qualified domain name of the host
 
358
                       where the Sieve script is executing.
 
359
 
 
360
      Capability name: location
 
361
      Description:     Type of service executing the Sieve script.
 
362
 
 
363
      Capability name: name
 
364
      Description:     The product name associated with the Sieve
 
365
                       interpreter.
 
366
 
 
367
      Capability name: phase
 
368
      Description:     Point relative to final delivery at which the
 
369
                       Sieve script is being evaluated.
 
370
 
 
371
      Capability name: remote-host
 
372
      Description:     Host name of remote SMTP client, if applicable
 
373
                       and available.
 
374
 
 
375
      Capability name: remote-ip
 
376
      Description:     IP address of remote SMTP client, if applicable
 
377
                       and available.
 
378
 
 
379
      Capability name: version
 
380
      Description:     The product version associated with the Sieve
 
381
                       interpreter.
 
382
 
 
383
      RFC number:      RFC 5183
 
384
      Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
 
385
 
 
386
 
 
387
 
 
388
 
 
389
 
 
390
 
 
391
 
 
392
 
 
393
 
 
394
Freed                       Standards Track                     [Page 7]
 
395
 
 
396
RFC 5183              Sieve Environment Extension               May 2008
 
397
 
 
398
 
 
399
7.  References
 
400
 
 
401
7.1.  Normative references
 
402
 
 
403
   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 
404
                 Requirement Levels", BCP 14, RFC 2119, March 1997.
 
405
 
 
406
   [RFC2821]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
 
407
                 April 2001.
 
408
 
 
409
   [RFC5228]     Guenther, P. and T. Showalter, "Sieve: An Email
 
410
                 Filtering Language", RFC 5228, January 2008.
 
411
 
 
412
   [RFC5231]     Segmuller, W. and B. Leiba, "Sieve Email Filtering:
 
413
                 Relational Extension", RFC 5231, January 2008.
 
414
 
 
415
7.2.  Informative references
 
416
 
 
417
   [EMAIL-ARCH]  Crocker, D., "Internet Mail Architecture", Work
 
418
                 in Progress, February 2008.
 
419
 
 
420
   [RFC3501]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
 
421
                 VERSION 4rev1", RFC 3501, March 2003.
 
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
Freed                       Standards Track                     [Page 8]
 
451
 
 
452
RFC 5183              Sieve Environment Extension               May 2008
 
453
 
 
454
 
 
455
Appendix A.  Acknowledgements
 
456
 
 
457
   Brian Carpenter, Dave Crocker, Cyrus Daboo, Philip Guenther, Kjetil
 
458
   Torgrim Homme, John Klensin, Mark Mallett, Alexey Melnikov, and
 
459
   Dilyan Palauzo provided helpful suggestions and corrections.
 
460
 
 
461
Author's Address
 
462
 
 
463
   Ned Freed
 
464
   Sun Microsystems
 
465
   3401 Centrelake Drive, Suite 410
 
466
   Ontario, CA  92761-1205
 
467
   USA
 
468
 
 
469
   Phone: +1 909 457 4293
 
470
   EMail: ned.freed@mrochek.com
 
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
Freed                       Standards Track                     [Page 9]
 
507
 
 
508
RFC 5183              Sieve Environment Extension               May 2008
 
509
 
 
510
 
 
511
Full Copyright Statement
 
512
 
 
513
   Copyright (C) The IETF Trust (2008).
 
514
 
 
515
   This document is subject to the rights, licenses and restrictions
 
516
   contained in BCP 78, and except as set forth therein, the authors
 
517
   retain all their rights.
 
518
 
 
519
   This document and the information contained herein are provided on an
 
520
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 
521
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 
522
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 
523
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 
524
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 
525
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
526
 
 
527
Intellectual Property
 
528
 
 
529
   The IETF takes no position regarding the validity or scope of any
 
530
   Intellectual Property Rights or other rights that might be claimed to
 
531
   pertain to the implementation or use of the technology described in
 
532
   this document or the extent to which any license under such rights
 
533
   might or might not be available; nor does it represent that it has
 
534
   made any independent effort to identify any such rights.  Information
 
535
   on the procedures with respect to rights in RFC documents can be
 
536
   found in BCP 78 and BCP 79.
 
537
 
 
538
   Copies of IPR disclosures made to the IETF Secretariat and any
 
539
   assurances of licenses to be made available, or the result of an
 
540
   attempt made to obtain a general license or permission for the use of
 
541
   such proprietary rights by implementers or users of this
 
542
   specification can be obtained from the IETF on-line IPR repository at
 
543
   http://www.ietf.org/ipr.
 
544
 
 
545
   The IETF invites any interested party to bring to its attention any
 
546
   copyrights, patents or patent applications, or other proprietary
 
547
   rights that may cover technology that may be required to implement
 
548
   this standard.  Please address the information to the IETF at
 
549
   ietf-ipr@ietf.org.
 
550
 
 
551
 
 
552
 
 
553
 
 
554
 
 
555
 
 
556
 
 
557
 
 
558
 
 
559
 
 
560
 
 
561
 
 
562
Freed                       Standards Track                    [Page 10]
 
563