Subject: Re: AW: [Simple] Data model - attempt at summary

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Nov 2004 16:27:18 -0500

> - service identification is not yet resolved if haven't missed
>   something. There seems to be some convergence in the group regarding 
>   URI as a basis but I think there are some issues here;
>   see also the draft 
> http://www.ietf.org/internet-drafts/draft-boehmer-simple-service-identification-00.txt
>   for a discussion of them. 

This is helpful description, although I have some doubts that adding a 
level of indirection is necessarily the way to resolve the problem. But 
that's a discussion for another day.

> - You once brought up the question of device identification. 
>   Probably I missed here something but I had the impression
>   that it remains an open issue.

I think that having all device components that report device information 
agree on a common, shared identifier is going to be painful and 
error-prone in practice. It seems more likely that they can agree on a 
small set of unique identifiers. Either way, this is largely speculation 
since we don't know yet whether we'll have devices publish their own 
data or whether various pieces of software also publish device 
information, which is then processed, merged, filtered and published.

It would be helpful, if only for my web notes, if somebody could 
summarize as to why they believe that a single identifier is likely to 
work in the multiple-publisher case. One possible compromise is to have 
a primary identifier that has the rule of an element identifier, but 
allow additional matching identifiers that the composer may use to do 
merging.

> 
> Another feature which, however, could be deferred is the question
> of internal service states as presence information (this relies to
> the fifth bullet in your web page). In the abovemetioned draft I
> touched a bit upon that but there is no clear answer on that in the
> moment. 

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

---

From: Boehmer Bernhard Com Berlin <[email-masked]>
Date: Thu, 11 Nov 2004 10:28:51 +0100

Anything is a hard word ... 
There are different issues which must be addressed:

- the description of services; I'm still not convinced
that the description via prefs is applicable to services
in general. Pointing to a description document is a way
to address that. A more direct poiting to such a doc would
be definitly nicer if possible.
- the inclusion of proprietary services: This is related to
 to the first point.
- the definition of a unique service ID which is well known.
The tmodel approach is a proposal to generate and publish
such an ID.

I would certainly appreciate other solutions are avoiding at 
least one of the two levels of indirection.
			Regards Bernhard

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Mittwoch, 10. November 2004 07:54
To: Henning Schulzrinne
Cc: Boehmer Bernhard ICM Berlin; Simple WG
Subject: Re: AW: AW: [Simple] Data model - attempt at summary

I agree with Henning here; I don't see how the layer of indirection 
solves anything.

-Jonathan R.

Henning Schulzrinne wrote:

> Boehmer Bernhard ICM Berlin wrote:
> 
>> Hi Henning,
>> service ID: certainly indirection has its drawbacks;
>> in this case the main question is whether the higher
>> flexibility of indirection outweighs the overhead
>> introduced with that. Actually, the whole XML schema
>> architecture is using it heavily (this becomes obvious
>> to me each time I edit XML schemas without being connected
>> to the Internet...:).
> 
> 
> While it is easy for a mobile provider to publish a UDDI directory entry 
> for its limited number of phones, say, it seems much harder for the 
> average user in a corporate network or using a provider. They will have 
> to rely on the provider or corporate network to host this information. 
> Unless you want to rely on web pages for configuration, every new source 
> of information means that there needs to be authentication, a means to 
> publish this information and to change it.
> 
> The only advantage of inclusion by reference is space saving. Otherwise, 
> whatever service description you include by reference can also be 
> included by value.
> 
> The space saving only matters if the mobile transmits the information. 
> This seems unlikely, even with inclusion.
> 
> Thus, I'm at a loss to see why adding another protocol machinery for 
> managing UDDI stores to every PUA or PA adds significant value that 
> outweighs the complexity incurred.
> 
> Henning
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com