Subject: [Simple] PIDFConn draft

From: "Jussi Ala-Kurikka" <[email-masked]>
Date: Thu, 6 Oct 2005 15:02:48 +0300

In current PIDF and its extensions, there are limited ways of expressing
features related to a network interface that receives packets sent to a
communication address (inside a <contact> element). It could be hard to map
the relative priorities of different communication addresses into decimal
numbers, and there could be a need for providing more information. I
participated in discussions in the Paris IETF about this issue and there
seemed to be a consensus that it should be discussed on the SIMPLE mailing
list.

Yesterday I submitted the first version of the PIDFConn draft which helps in
providing specific information related to a communication address. PIDFConn
is available at
http://www.ietf.org/internet-drafts/draft-ala-kurikka-simple-pidfconn-00.txt
.

The authors welcome your comments. Hopefully PIDFConn arises discussion
about whether we need to extend PIDF with these things (and to what extent),
if not more.

BR,
Jussi
____________________________________________________________________
Jussi Ala-Kurikka, Researcher
MediaTeam Oulu Group, University of Oulu Erkki Koiso-Kanttilan katu 3,
FIN-90014 University of Oulu, Finland
e-mail: [email-masked], http://www.mediateam.oulu.fi tel.
+358-8-5532811, fax +358-8-5532534

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2005 13:12:23 -0400

Jussi,

I just took a quick look.

I find the logical data model quite confusing. You put the connectivity 
element in the devcaps, but then you need to link it back to the service 
tuples that it supports. Meanwhile service tuples need to link to the 
device elements that they are bound to.

If the goal is to help a watcher to decide when/if to communicate based 
on the predicted characteristics of the connection, then it must be 
possible to determine how the way it connects determines which 
connectivity will apply. This can only happen if the contact is 
associated with a single connectivity.

In the existing extended pidf model, a service tuple can have only one 
contact, but can be bound to any number of devices. So there is a 
potential for ambiguity in your extension.

Why don't you just associate your connectivity extension with a tuple 
rather than with a device?

	Paul