Subject: attribute strings with keyword and value attributes

From: David Arnold <[email-masked]>
Date: Thu, 18 Feb 1999 20:18:49 +1000

hi all!

i have a problem encoding an attribute string as a result of an
AttrRqst.

assume that two services have registered with a DA, using the same
service type, and an attribute whose tag is "x-foo" (ie. non-standard,
not constrained by a service template).

the first registration uses "x-foo" as a keyword, while the second
supplies a value (or value list).

suppose then that a UA sends an AttrRqst for the service type of these
two registrations.  in attempting to marshal the combined attribute
string, the "x-foo" attribute has not only inconsistent types, but
also a keyword/value clash.

what should an implementation do in this circumstance?

at the end of protocol-v2-12, section 5 it notes that inconsistently
typed attribute value lists should be rejected.  but it does not imply
that this extends across multiple registrations.  however, one
possibility is to refuse the second registration (with
INVALID_REGISTRATION) on the basis that the first has established an
implicit type for "x-foo".  however, that's not very obvious for a
client -- it could work one second and fail the next, depending on the
registration database of the DA.

another would be to drop keyword attributes in the returned attribute
string where there were valued attributes with the same tag.  but this
doesn't overcome the secondary problem of inconsistent typing (one
registration could supply (x-foo=3) and the other (x-foo=bar))

any comments would be appreciated.

thanks,

-- David Arnold   ,=================================================
================='                             +617 33654310 (voice)
CRC for Distributed Systems Technology         +617 33654311   (fax)
University of Queensland                    [email-masked] (email)
Australia                     <http://www.pobox.com/~davida>   (web)

---

From: James Kempf <[email-masked]>
Date: Fri, 19 Feb 1999 08:17:19 -0800 (PST)

>registration could supply (x-foo=3) and the other (x-foo=bar))

There is no requirement in protocol-v2-12 that attribute lists
be consistently typed across advertisements only that they be 
consistently typed in one advertisement. 

From the protocol standpoint, therefore, an AttrRqst by service
type could return a list with an inconsistent implied type
if one advertisment had attribute (x-foo=3) and (x-foo=bar).
The returned list would be (x-foo=2,bar).

A similar problem occurs with booleans.
Suppose I make an AttrRqst by service type for a boolean attribute
"foo" and suppose one advertisement has the attribute set to true
and another to false. Then the AttrRply must return "(foo=true,false)".
Multivalued boolean attribute lists are, in general, prohibited, but
in this case they are allowed because the AttrRqst by service type
is designed to give the client an idea of the range of values
exhibited by accessable service advertisements.

So, I would suggest that this case is similar. From an API standpoint,
the C API is not impacted because it merely reflects the returned
attribute list string to the client. For the Java API, the returned
ServiceLocationAttribute would have a values list that was not
consistent, just as is the case with booleans.

This means, of course, that the returned ServiceLocationAttribute
can't be used to register something outgoing because the list is
inconsistent.

How does this sound?

		jak