2004/id/draft-ietf-iiir-transponders-01.txt

IETF IIIR Working Group                                   Chris Weider
INTERNET--DRAFT                                    Merit Network, Inc.
<draft-ietf-iiir-transponders-01.txt>                    October, 1993

                        Resource Transponders

Status of this Memo

In this paper, the author describes a mechanism for automatically 
maintaining resource location systems which contain pointers to 
resources.

        This document is an Internet Draft.  Internet Drafts are working
        documents of the Internet Engineering Task Force (IETF), its     
        Areas, and its Working Groups.  Note that other groups may also 
        distribute working documents as Internet Drafts.

        Internet Drafts are draft documents valid for a maximum of six
        months. Internet Drafts may be updated, replaced, or obsoleted
        by other documents at any time. It is not appropriate to use 
        Internet Drafts as reference material or to cite them other than
        as a "working draft" or "work in progress."

        Please check the I-D abstract listing contained in each Internet
        Draft directory to learn the current status of this or any 
        other Internet Draft.

        This Internet Draft expires April 22, 1993.

Abstract

Although a number of systems have been created in the last several years
to provide resource location and navigation on the Internet, the 
information contained in these systems must be maintained and updated by 
hand. This paper describes an automatic mechanism, the resource 
transponder, for maintaining resource location information.

Author's note:

This document is being circulated as a research paper; consequently
there are no protocol specifications or anything of the sort. I hope 
that we can go from here and actually get some implementation 
experience.

1. Introduction

In the past few years, we've seen the invention and growth of a number 
of information location systems on the Internet, e.g. archie, Gopher, 
and WAIS. However, as these systems have become widely deployed, a 
number of maintenance and security problems have arisen with them. Some 
of the major ones

INTERNET--DRAFT         Resource Transponders                        Weider

  1) Out of necessity, most of these systems contain pointers to the
     desired resources rather than the resources themselves. Therefore,
     if a resource becomes obsolete, is modified, or is moved, the
     location system must be updated by hand. Some systems, such as 
     Archie and Veronica, proactively create updated indexes by
     contacting every resource on a certain time schedule. However, this
     means that the system can be wildly out of date, depending on the
     interval between polls of the resources. This process can be highly 
     inefficient depending on the percentage of information that has
     changed.

  2) Conversely, anyone who maintains a resource that they wish indexed
     must keep track of every directory which contains a pointer to that
     resource, so that if it is modified, all the directories can be
     updated. This obviously is an optimistic scenario.

  3) Many organizations which have installed these systems do not have
     the available resources or expertise to maintain the information in
     the systems. Thus we have long periods where the information
     drifts, then a short period when the information is updated again. 

  4) Even though these systems are almost always out of date today, this
     problem will become increasingly harder for humans to manage by
     hand as everyone on the net becomes their own publisher. Also, as
     the net speeds up and people rely more and more on accurate
     information, human-induced delays in updates of these systems will
     become increasingly intolerable.

  5) Most, if not all, of these systems provide no security whatsoever;
     if a pointer to a resource appears in a locator system, then it is
     assumed to be meant for public consumption. There are many
     potential information providers who would like to use publicly
     deployed information systems to publish to a very selected
     clientele, and do not wish to allow the whole net access to their
     resources.

2: Requirements for a solution

There are several objectives which must be met by any proposed solution 
to these problems:

  1) We need to decrease the personnel resources needed for indexing and
     pointer maintenance.

  2) We need to increase the reliability and accuracy of the information
     held in resource location systems.

  3) We need to provide some mechanisms for security, particularly by
     mediating access to the resources

INTERNET--DRAFT         Resource Transponders                        Weider


  4) We need to make it easy for non-experts, such as librarians,
     archivists, and database maintainers, to announce their new
     resources to the various resource location services.

Many of these problems can be solved by a 'resource transponder' 
mechanism.

3: Resource Transponders

The resource transponder system works by adding two new layers to every 
resource: metainformation and an agent to update a resource location 
system (RLS) with that metainformation. The metainformation layer is 
physically attached to every resource, so that when the resource is 
moved or altered, the metainformation is immediately available to update 
the RLS. The agent layer may also be attached to the resource or may not 
be; the implications of both of these options are discussed in detail 
below.

3.1: Metainformation

The metainformation layer of a given resource contains any information 
which might be required to create a pointer to this resource, and any 
information which may be useful for indicating how to catalog or index 
the resource. For example, the metainformation layer of a text document 
might contain such things as the Uniform Resource Name (URN) of the 
document [Weider 1993], the title of the document, a Uniform Resource 
Locator (URL) for the document [Berners-Lee 1993], the size of the 
document, etc. Thus the metainformation layer contains data _about_ the 
resource to which it is attached.

This metainformation is expected to be modifiable. For example, the 
metainformation layer may contain a history of where this particular
copy of a resource has been.  Let's say that a resource/transponder pair
has been moved. When it gets to its new location, the agent can then 
attempt to contact the resource at its old location to determine whether 
the resource is still there (in which case the agent will simply cause 
the new location to be added to the RLS) or whether the resource is not 
there (in which case the agent can tell the RLS to add the current 
pointer and delete the old one). 

A number of other possibilities for the contents of the metainformation
level are contained in section 4.1.    

3.2: Agents

The agent layer of a given resource contains an executable program which
is responsible for reading the metainformation attached to the resource 
and using that information to update a RLS. It is also responsible for

INTERNET--DRAFT         Resource Transponders                        Weider

updating the metainformation where necessary and for running any 
indexing programs required by the RLS it is attempting to update. 

When the tools required to build agents are constructed and deployed, 
the author expects the agents to begin mediating access to the resource, 
particularly for agents attached to resources which are not currently
considered active processes, such as text files and digitized images.
In this futuristic model, someone wishing to read a given document would
have to first negotiate access to the data with the agent; the agent 
would then be responsible for delivering the data to the client. 
However, it is expected that this type of agent will not be widely 
deployed for some time. 

Different ways of implementing agents are discussed in section 4.2.

4: Models for implementations of resource transponders

4.1: Models for implementations of the metainformation layer

The metainformation layer can be implemented in a number of ways, 
depending on the resource with which it is associated. For an 'active' 
resource, such as an on-line catalog or a mail-based service, the 
metainformation can be stored in a file with a well-known name in the 
software distribution. Alternatively, the metainformation could be 
stored as a record in the data which the resource serves. For a text 
document, the metainformation could be stored as the first or last N 
bytes of the document (which would break a number of editors and file 
display techniques, but would guarantee that the metainformation is 
moved with the resource), or perhaps as a file with a logically 
associated name (paper2.meta associated with paper2.txt, for example). 
The problem with this second approach is that the user must know that 
they have to move the metainformation with the file itself, or things 
will start breaking. If an agent is explicitly attached to the resource, 
the agent could contain the metainformation internally.

In any case, the resource transponder system must be able to guarantee 
that the metainformation is moved when the resource is moved.

4.2: Models for implementations of the agents

The agent layer can also be implemented in a number of ways, depending
on such things as system loads, desired sizes of resources, multitasking
capabilities, etc.

The easiest and for many unitasking systems the cleanest way of 
implementing an agent is to have one agent per computer. Then when a 
resource is moved onto that computer, the agent is explicitly activated 
and notified where the new resource is. For example, let's say that 
someone wishes to download a copy of a resource and then let the RLS 
know that that resource is available for public consumption. She would 
download the resource and then run the agent, which would then notify

INTERNET--DRAFT         Resource Transponders                        Weider

the RLS and update the metainformation attached to the resource. This 
model could also be used to track files on a LAN, or to provide local 
location services with no need to run a larger RLS.

Another model for implementation of the agent is to have one agent per
resource. In this model, the agent would be moved along with the
resource and the metainformation. The agent could be implemented in a 
file which would be associated with the resource; in that case the agent 
would have to be explicitly activated when the resource was moved. 
Alternatively, the agent/metainformation/resource system could be 
implemented as one system, or in one file. In this case, the agent 
itself would always be active, and would be responsible for mediating 
access to the resource. When one did a 'telnet' to a resource with an 
active agent, the agent would accept the telnet connection and be 
responsible for providing security and translation for the data. This 
could provide great security for resources while still allowing pointers 
to them to be placed in public RLS's; the data in the resource could be 
encrypted, with the agent responsible for decrypting it. This option is 
explored more fully in Section 5.

5: Transponders and Objects

Section 4.2 details several methods of implementing resource transponder
agents. The technique of encapsulating the metainformation *and* the 
data for the resource 'inside' the agent brings up several interesting 
possibilities. As noted, once the data is encapsulated in the agent, all 
actions on the resource are mediated by the agent. In essence, 
encapsulating the resource this way allows the resource to be treated as 
an active, 'animate' object on the network. With the appropriate 
functionality in the agent, the resource could also maintain additional 
information about where it has been, and can also provide large subsets 
of the general maintenance functionality required by a rapidly changing 
information mesh. 

5.1: Possible Functionality of Active Resources

This is an exploration of several possible functions which may be 
available on resource objects; this is not intended to be an exhaustive 
list.

5.1.1: Replicate

Sending this command to a resource object causes it to attempt to create 
a copy of itself at a given location in the network. To achieve this, 
the resource will have to negotiate permissions with the target system. 
This functionality would allow:

Automatic mirroring of resource objects. If a transponder is attached to 
a resource which is being updated frequently, and that resource is being 
mirrored in a number of other places, the transponder agent could use 
this function to maintain the other copies

INTERNET--DRAFT         Resource Transponders                        Weider

Load balancing. In the resource object model, access to a resource is 
gained by negotiation with the attached transponder agent. Thus, as a 
part of the metainformation, the agent can maintain load information, 
such as a history of access information, elapsed time for given 
operations, etc. The agent can then determine if there is an access or 
load problem because of heavy demand for the data in the resource. If 
there is a load problem, it can then replicate itself and notify the 
resource location system that a new copy has been created. 

5.1.2: Annotate

In the resource object model, every resource exists on the net as an 
independent entity, moving around, copying itself, or perhaps just 
sitting still. Many of these resources will be academic papers, books, 
journal articles, even interorganizational memos. Discovery of a given 
resource will require a sophisticated resource location system, which we 
are just now starting to build with the various information delivery 
tools available. However, once we've found an interesting resource, it 
will be a much more difficult task to find the body of commentary and 
annotation on this resource. The resource object can alleviate this 
problem by maintaining a pointer to a body of commentary in the 
metainformation of the resource. When someone wishes to annotate a given 
resource, or to retrieve annotations created by other people, they would 
then send an 'annotate' command to the resource object, and the resource 
object would then return the pointer to the resource which contains the 
annotations. Since the resource object which contains the annotations 
would also have a transponder mechanism, annotations could then be added 
and the resource location system would be updated.

5.1.3: Destroy

This function would cause the resource object to be deleted after the 
resource location system was updated. The agent would be responsible for 
verifying that the requester had the proper permissions to delete the 
resource; in addition, the resource object could determine how many 
other copies of itself existed and could inform the requester, asking 
for a confirmation before deleting itself.

6: Conclusion

As shown in sections 3 and 4, the resource transponder or something like 
it could be enormously valuable no matter how it is implemented. In 
addition, active resource objects allow for additional functionality 
which will be very helpful for the next phases of the Internet 
Information Infrastructure. Therefore, I wish to encourage the reader to 
look at implementation strategies and help build this.

INTERNET--DRAFT         Resource Transponders                        Weider
 
7: References

[Berners-Lee 1993] Berners-Lee, Tim, 'Uniform Resource Locators', 
Internet Draft, July 1993. Available as
<ftp://nic.merit.edu/documents/ietf/draft-ietf-uri-url-01.txt>

[Weider 1993] Weider, Chris, and Peter Deutsch, 'Uniform Resource 
Names', Internet Draft, October 1993. Available as
<ftp://nic.merit.edu/documents/ietf/draft-ietf/uri-resource-names-
01.txt>

8: Author's address

Chris Weider, clw@merit.edu
Merit Network, Inc.
2901 Hubbard, Pod G
Ann Arbor, MI 48105

Phone: (313) 747-2730
Fax: (313) 747-3185

1	IETF IIIR Working Group Chris Weider
2	INTERNET--DRAFT Merit Network, Inc.
3	<draft-ietf-iiir-transponders-01.txt> October, 1993
4
5	Resource Transponders
6
7	Status of this Memo
8
9	In this paper, the author describes a mechanism for automatically
10	maintaining resource location systems which contain pointers to
11	resources.
12
13	This document is an Internet Draft. Internet Drafts are working
14	documents of the Internet Engineering Task Force (IETF), its
15	Areas, and its Working Groups. Note that other groups may also
16	distribute working documents as Internet Drafts.
17
18	Internet Drafts are draft documents valid for a maximum of six
19	months. Internet Drafts may be updated, replaced, or obsoleted
20	by other documents at any time. It is not appropriate to use
21	Internet Drafts as reference material or to cite them other than
22	as a "working draft" or "work in progress."
23
24	Please check the I-D abstract listing contained in each Internet
25	Draft directory to learn the current status of this or any
26	other Internet Draft.
27
28	This Internet Draft expires April 22, 1993.
29
30	Abstract
31
32	Although a number of systems have been created in the last several years
33	to provide resource location and navigation on the Internet, the
34	information contained in these systems must be maintained and updated by
35	hand. This paper describes an automatic mechanism, the resource
36	transponder, for maintaining resource location information.
37
38	Author's note:
39
40	This document is being circulated as a research paper; consequently
41	there are no protocol specifications or anything of the sort. I hope
42	that we can go from here and actually get some implementation
43	experience.
44
45	1. Introduction
46
47	In the past few years, we've seen the invention and growth of a number
48	of information location systems on the Internet, e.g. archie, Gopher,
49	and WAIS. However, as these systems have become widely deployed, a
50	number of maintenance and security problems have arisen with them. Some
51	of the major ones
52
53	INTERNET--DRAFT Resource Transponders Weider
54
55	1) Out of necessity, most of these systems contain pointers to the
56	desired resources rather than the resources themselves. Therefore,
57	if a resource becomes obsolete, is modified, or is moved, the
58	location system must be updated by hand. Some systems, such as
59	Archie and Veronica, proactively create updated indexes by
60	contacting every resource on a certain time schedule. However, this
61	means that the system can be wildly out of date, depending on the
62	interval between polls of the resources. This process can be highly
63	inefficient depending on the percentage of information that has
64	changed.
65
66	2) Conversely, anyone who maintains a resource that they wish indexed
67	must keep track of every directory which contains a pointer to that
68	resource, so that if it is modified, all the directories can be
69	updated. This obviously is an optimistic scenario.
70
71	3) Many organizations which have installed these systems do not have
72	the available resources or expertise to maintain the information in
73	the systems. Thus we have long periods where the information
74	drifts, then a short period when the information is updated again.
75
76	4) Even though these systems are almost always out of date today, this
77	problem will become increasingly harder for humans to manage by
78	hand as everyone on the net becomes their own publisher. Also, as
79	the net speeds up and people rely more and more on accurate
80	information, human-induced delays in updates of these systems will
81	become increasingly intolerable.
82
83	5) Most, if not all, of these systems provide no security whatsoever;
84	if a pointer to a resource appears in a locator system, then it is
85	assumed to be meant for public consumption. There are many
86	potential information providers who would like to use publicly
87	deployed information systems to publish to a very selected
88	clientele, and do not wish to allow the whole net access to their
89	resources.
90
91	2: Requirements for a solution
92
93	There are several objectives which must be met by any proposed solution
94	to these problems:
95
96	1) We need to decrease the personnel resources needed for indexing and
97	pointer maintenance.
98
99	2) We need to increase the reliability and accuracy of the information
100	held in resource location systems.
101
102	3) We need to provide some mechanisms for security, particularly by
103	mediating access to the resources
104
105	INTERNET--DRAFT Resource Transponders Weider
106
107
108	4) We need to make it easy for non-experts, such as librarians,
109	archivists, and database maintainers, to announce their new
110	resources to the various resource location services.
111
112	Many of these problems can be solved by a 'resource transponder'
113	mechanism.
114
115	3: Resource Transponders
116
117	The resource transponder system works by adding two new layers to every
118	resource: metainformation and an agent to update a resource location
119	system (RLS) with that metainformation. The metainformation layer is
120	physically attached to every resource, so that when the resource is
121	moved or altered, the metainformation is immediately available to update
122	the RLS. The agent layer may also be attached to the resource or may not
123	be; the implications of both of these options are discussed in detail
124	below.
125
126	3.1: Metainformation
127
128	The metainformation layer of a given resource contains any information
129	which might be required to create a pointer to this resource, and any
130	information which may be useful for indicating how to catalog or index
131	the resource. For example, the metainformation layer of a text document
132	might contain such things as the Uniform Resource Name (URN) of the
133	document [Weider 1993], the title of the document, a Uniform Resource
134	Locator (URL) for the document [Berners-Lee 1993], the size of the
135	document, etc. Thus the metainformation layer contains data _about_ the
136	resource to which it is attached.
137
138	This metainformation is expected to be modifiable. For example, the
139	metainformation layer may contain a history of where this particular
140	copy of a resource has been. Let's say that a resource/transponder pair
141	has been moved. When it gets to its new location, the agent can then
142	attempt to contact the resource at its old location to determine whether
143	the resource is still there (in which case the agent will simply cause
144	the new location to be added to the RLS) or whether the resource is not
145	there (in which case the agent can tell the RLS to add the current
146	pointer and delete the old one).
147
148	A number of other possibilities for the contents of the metainformation
149	level are contained in section 4.1.
150
151	3.2: Agents
152
153	The agent layer of a given resource contains an executable program which
154	is responsible for reading the metainformation attached to the resource
155	and using that information to update a RLS. It is also responsible for
156
157	INTERNET--DRAFT Resource Transponders Weider
158
159	updating the metainformation where necessary and for running any
160	indexing programs required by the RLS it is attempting to update.
161
162	When the tools required to build agents are constructed and deployed,
163	the author expects the agents to begin mediating access to the resource,
164	particularly for agents attached to resources which are not currently
165	considered active processes, such as text files and digitized images.
166	In this futuristic model, someone wishing to read a given document would
167	have to first negotiate access to the data with the agent; the agent
168	would then be responsible for delivering the data to the client.
169	However, it is expected that this type of agent will not be widely
170	deployed for some time.
171
172	Different ways of implementing agents are discussed in section 4.2.
173
174	4: Models for implementations of resource transponders
175
176	4.1: Models for implementations of the metainformation layer
177
178	The metainformation layer can be implemented in a number of ways,
179	depending on the resource with which it is associated. For an 'active'
180	resource, such as an on-line catalog or a mail-based service, the
181	metainformation can be stored in a file with a well-known name in the
182	software distribution. Alternatively, the metainformation could be
183	stored as a record in the data which the resource serves. For a text
184	document, the metainformation could be stored as the first or last N
185	bytes of the document (which would break a number of editors and file
186	display techniques, but would guarantee that the metainformation is
187	moved with the resource), or perhaps as a file with a logically
188	associated name (paper2.meta associated with paper2.txt, for example).
189	The problem with this second approach is that the user must know that
190	they have to move the metainformation with the file itself, or things
191	will start breaking. If an agent is explicitly attached to the resource,
192	the agent could contain the metainformation internally.
193
194	In any case, the resource transponder system must be able to guarantee
195	that the metainformation is moved when the resource is moved.
196
197	4.2: Models for implementations of the agents
198
199	The agent layer can also be implemented in a number of ways, depending
200	on such things as system loads, desired sizes of resources, multitasking
201	capabilities, etc.
202
203	The easiest and for many unitasking systems the cleanest way of
204	implementing an agent is to have one agent per computer. Then when a
205	resource is moved onto that computer, the agent is explicitly activated
206	and notified where the new resource is. For example, let's say that
207	someone wishes to download a copy of a resource and then let the RLS
208	know that that resource is available for public consumption. She would
209	download the resource and then run the agent, which would then notify
210
211	INTERNET--DRAFT Resource Transponders Weider
212
213	the RLS and update the metainformation attached to the resource. This
214	model could also be used to track files on a LAN, or to provide local
215	location services with no need to run a larger RLS.
216
217	Another model for implementation of the agent is to have one agent per
218	resource. In this model, the agent would be moved along with the
219	resource and the metainformation. The agent could be implemented in a
220	file which would be associated with the resource; in that case the agent
221	would have to be explicitly activated when the resource was moved.
222	Alternatively, the agent/metainformation/resource system could be
223	implemented as one system, or in one file. In this case, the agent
224	itself would always be active, and would be responsible for mediating
225	access to the resource. When one did a 'telnet' to a resource with an
226	active agent, the agent would accept the telnet connection and be
227	responsible for providing security and translation for the data. This
228	could provide great security for resources while still allowing pointers
229	to them to be placed in public RLS's; the data in the resource could be
230	encrypted, with the agent responsible for decrypting it. This option is
231	explored more fully in Section 5.
232
233	5: Transponders and Objects
234
235	Section 4.2 details several methods of implementing resource transponder
236	agents. The technique of encapsulating the metainformation and the
237	data for the resource 'inside' the agent brings up several interesting
238	possibilities. As noted, once the data is encapsulated in the agent, all
239	actions on the resource are mediated by the agent. In essence,
240	encapsulating the resource this way allows the resource to be treated as
241	an active, 'animate' object on the network. With the appropriate
242	functionality in the agent, the resource could also maintain additional
243	information about where it has been, and can also provide large subsets
244	of the general maintenance functionality required by a rapidly changing
245	information mesh.
246
247	5.1: Possible Functionality of Active Resources
248
249	This is an exploration of several possible functions which may be
250	available on resource objects; this is not intended to be an exhaustive
251	list.
252
253	5.1.1: Replicate
254
255	Sending this command to a resource object causes it to attempt to create
256	a copy of itself at a given location in the network. To achieve this,
257	the resource will have to negotiate permissions with the target system.
258	This functionality would allow:
259
260	Automatic mirroring of resource objects. If a transponder is attached to
261	a resource which is being updated frequently, and that resource is being
262	mirrored in a number of other places, the transponder agent could use
263	this function to maintain the other copies
264
265	INTERNET--DRAFT Resource Transponders Weider
266
267	Load balancing. In the resource object model, access to a resource is
268	gained by negotiation with the attached transponder agent. Thus, as a
269	part of the metainformation, the agent can maintain load information,
270	such as a history of access information, elapsed time for given
271	operations, etc. The agent can then determine if there is an access or
272	load problem because of heavy demand for the data in the resource. If
273	there is a load problem, it can then replicate itself and notify the
274	resource location system that a new copy has been created.
275
276	5.1.2: Annotate
277
278	In the resource object model, every resource exists on the net as an
279	independent entity, moving around, copying itself, or perhaps just
280	sitting still. Many of these resources will be academic papers, books,
281	journal articles, even interorganizational memos. Discovery of a given
282	resource will require a sophisticated resource location system, which we
283	are just now starting to build with the various information delivery
284	tools available. However, once we've found an interesting resource, it
285	will be a much more difficult task to find the body of commentary and
286	annotation on this resource. The resource object can alleviate this
287	problem by maintaining a pointer to a body of commentary in the
288	metainformation of the resource. When someone wishes to annotate a given
289	resource, or to retrieve annotations created by other people, they would
290	then send an 'annotate' command to the resource object, and the resource
291	object would then return the pointer to the resource which contains the
292	annotations. Since the resource object which contains the annotations
293	would also have a transponder mechanism, annotations could then be added
294	and the resource location system would be updated.
295
296	5.1.3: Destroy
297
298	This function would cause the resource object to be deleted after the
299	resource location system was updated. The agent would be responsible for
300	verifying that the requester had the proper permissions to delete the
301	resource; in addition, the resource object could determine how many
302	other copies of itself existed and could inform the requester, asking
303	for a confirmation before deleting itself.
304
305	6: Conclusion
306
307	As shown in sections 3 and 4, the resource transponder or something like
308	it could be enormously valuable no matter how it is implemented. In
309	addition, active resource objects allow for additional functionality
310	which will be very helpful for the next phases of the Internet
311	Information Infrastructure. Therefore, I wish to encourage the reader to
312	look at implementation strategies and help build this.
313
314	INTERNET--DRAFT Resource Transponders Weider
315
316	7: References
317
318	[Berners-Lee 1993] Berners-Lee, Tim, 'Uniform Resource Locators',
319	Internet Draft, July 1993. Available as
320	<ftp://nic.merit.edu/documents/ietf/draft-ietf-uri-url-01.txt>
321
322	[Weider 1993] Weider, Chris, and Peter Deutsch, 'Uniform Resource
323	Names', Internet Draft, October 1993. Available as
324	<ftp://nic.merit.edu/documents/ietf/draft-ietf/uri-resource-names-
325	01.txt>
326
327	8: Author's address
328
329	Chris Weider, clw@merit.edu
330	Merit Network, Inc.
331	2901 Hubbard, Pod G
332	Ann Arbor, MI 48105
333
334	Phone: (313) 747-2730
335	Fax: (313) 747-3185
336