headers
Jonathan Rosenberg | 1 Feb 2005 02:29
Picon
Favicon

Re: Namespaces and XCAP

This particular behavior in XPath 1.0 is IMHO a bug, and appears to have 
been corrected in XPath 2.0.

We are not normatively dependent on XPath, so we can do what we choose. 
I would propose that the application usage specify the default 
namespace. Otherwise, every single XCAP URI will need to contain a 
xmlns() xpointer expression declaring the default namespace for the 
documents, all of which are likely to use the target namespace as the 
default.

If we specify this, an xcap expression would be compatible with xpath 
2.0 I believe.

-Jonathan R.

Nelson Hung wrote:

> I agree that 5(A) is the best option.
> 
> But one thing about default namespace, XPath Specification 1.0 explicitly
> disallows the use of default namespace in an XPath expression...
> 
> 
> http://www.w3.org/TR/xpath#node-tests
> 
> 
> "A QName in the node test is expanded into an expanded-name using the
> namespace declarations from the expression context. This is the same way
> expansion is done for element type names in start and end-tags except that
> the default namespace declared with xmlns is not used: if the QName does not
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joel M. Halpern | 1 Feb 2005 02:52

Re: Namespaces and XCAP

Sounds like a good idea to me.  It makes the normal case efficient, and 
matches the human expectation.

Yours,
Joel

At 08:29 PM 1/31/2005, Jonathan Rosenberg wrote:
>We are not normatively dependent on XPath, so we can do what we choose. I 
>would propose that the application usage specify the default namespace. 
>Otherwise, every single XCAP URI will need to contain a xmlns() xpointer 
>expression declaring the default namespace for the documents, all of which 
>are likely to use the target namespace as the default.
>
>If we specify this, an xcap expression would be compatible with xpath 2.0 
>I believe.
>
>-Jonathan R.
Permalink | Reply | 0 comments |
headers
jari urpalainen | 1 Feb 2005 08:23
Picon

Re: Namespaces and XCAP

On Mon, 2005-01-31 at 15:55 -0500, ext Jonathan Rosenberg wrote:
> Folks,
> 
> One of the issues that has come up during the last call period for xcap 
> was the way namespaces are used during the URI matching operation. The 
> way it works today is that the namespace contexts for evaluating the 
> xcap URI are constructed as you traverse through the document. The 
> namespace prefixes in the URI therefore need to be defined using 
> namepsace bindings defined in the document itself.
> 
> This has two major drawbacks that have been pointed out:
> 
> 1. it requires the XCAP client to have the document in hand ahead of 
> time, just to know the namespace bindings
> 
> 2. it prohibits the usage of existing off-the-shelf xpath libraries to 
> support xcap. These libraries require namespace bindings to be provided 
> PRIOR to the evaluation of an expression against a document.
> 
> We have in the past agreed that an xcap client must be able to perform 
> operations like insertion of a buddy into a buddy list, without having 
> the full buddy list document stored locally. The current matching rules 
> make that impossible. That would seem to be a fairly significant 
> limitation and therefore one that we need to address.
> 
> The alternatives are fairly limited. They are, as far as I can tell:
> 
> 1. Server defined namespace bindings
> 
> The server can define bindings between namespace prefixes and namespace
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jonathan Rosenberg | 1 Feb 2005 08:43
Picon
Favicon

Re: Namespaces and XCAP

inline.

jari urpalainen wrote:

>>So, which to use? Considering the issues involved, I think the best 
>>option is 5(A).
>>
>>Comments?
>>
>>Thanks,
>>Jonathan R.
>>
>>
> 
> 
> In principle I am in favor of 5A. However, I have a difficulty
> understanding why we should use a different syntax than what xpointer
> spec has ?

Why is it different? I was proposing to use the xmlns xpointer 
expression exactly as defined.

> 
> http://www.w3.org/TR/WD-xptr
> 
> xmlns(x=http://example.com/foo) xpointer(//x:a)

Oh, so you are saying ditch the whole xpath thing in favor of xpointers 
for element naming?
(Continue reading)

Permalink | Reply | 9 comments |
headers
Suganya | 2 Feb 2005 01:04

sip and dns

Hi,

I have the following doubts and need some help.

a) In order to contruct DNS query, I googled-up and found RFCs 1034 and
1035. But it doesn't talk of SIP. Can those guidelines be used for
constructing the DNS for SIP related queries?

b) Where to send the DNS query from UAC?

c) Unlike RFC 3261 which clearly tells how to construct invite, ack, etc...
messages, RFC 3263 specifies no syntax or query format to construct the DNS
query.

Regards,
B.Suganya
Permalink | Reply | 0 comments |
headers
Sharath Chandra | 1 Feb 2005 13:30
Picon

On Class

How does existing Presence data model address the following issues ?

1) Unique identity for a user across the domains and networks. For a
presence document to be complete it may need to handle alias for a
user within the same network as well as across the domains and
networks. Presence informations multiple application (not sip based
sources) also needs to be handled. Is there a proposed architecture
for such requirement

2) Categorizing the watchers into groups for a presentity to specify
different levels of privacy and trust. Like Family, Friends,
Colleagues etc. I believe once the grouping/class is available i can
have more control on what data i can disclose to which class and i can
make a authorization document using XCAP.

Thanks,
Sharath
Permalink | Reply | 1 comment |
headers
Aki Niemi | 1 Feb 2005 14:44
Picon

Single tuple or many tuples (was: Re: another try at data model compromise regarding unique service URI)


ext Paul Kyzivat wrote:

...snip...

> For devices with the real estate, it would be better to simply display 
> multiple icons for each buddy indicating what capabilities are currently 
> available. (Perhaps icons of phones and cameras can turn from red to 
> green.)

I don't buy this. Think of a "doom" icon that can be either red, green, 
or  indicate deathmatch. Capabilities are uninportant, it's the service 
that is composed of those capabilities that is important.

And do you really think users will generally be happy to interpret that 
someone is available for push-to-talk by examining a set of three (or 
more) icons?

...snip...

>> Even further, for some services, audio can be "on" while for others 
>> "off". Take for example, push-to-talk, voice, and video call in a 
>> single device. How can you describe a different stratus for each of 
>> these services using a single tuple?
> 
> 
> I still don't understand your model of how the device works.
> 
> You seem to have in mind a "video service" that includes both voice and 
> video, and a separate "audio service" that includes only audio. And then
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Kyzivat | 1 Feb 2005 15:57
Picon
Favicon

Re: Single tuple or many tuples (was: Re: another try at data model compromise regarding unique service URI)


Aki Niemi wrote:
> 
> 
> ext Paul Kyzivat wrote:
> 
> ...snip...
> 
>> For devices with the real estate, it would be better to simply display 
>> multiple icons for each buddy indicating what capabilities are 
>> currently available. (Perhaps icons of phones and cameras can turn 
>> from red to green.)
> 
> I don't buy this. Think of a "doom" icon that can be either red, green, 
> or  indicate deathmatch. Capabilities are uninportant, it's the service 
> that is composed of those capabilities that is important.

I don't understand your point at all.

It seems to me that either:

- you have a separate tuple/service for Doom, with its own unique
   contact that I can call. In this case doom itself may have
   "doom" capability, and perhaps audio, video, etc. as well.

   you then have other contacts with differing sets of capabilities
   and different contact addresses. Perhaps one with basic voice.

- you have a single multipurpose tuple/service. It has capabilities
   for voice, and maybe doom as well.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian Rosen | 1 Feb 2005 16:49

RE: Single tuple or many tuples (was: Re: another try atdata model compromise regarding unique service URI)

I've pretty much stayed out of this whole set of threads, but this one
really had me wondering where everyone's head is again.

We're getting wrapped around the axle of not having a definition of
"service" again.

Specifically, I believe that the Doom case you describe below is a Service
called Doom that has a number of media streams it supports.  It does NOT
offer a voice SERVICE, the DOOM service includes game, audio and video media
capability.

Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly
using the same hardware, possibly not.  You don't care. 

PTT is a SERVICE.  It supports voice, possibly video and has floor control.
But there is nothing in the set of capabilities such as: audio=true,
video=false, duplex=full, floor-control=false that could possibly indicates
PTT isn't there.  A dumb but straightforward audio conference phone could
have exactly the same capabilities.  The dumb conference phone could have
that also.  The "floor control=true" and "duplex=half" capabilities, in
particular, are not peculiar to PTT.  A cell phone with PTT today would have
at least two services (voice and PTT).  Today, those services are separate;
even the voice path is separate in many implementations.

And please keep in mind that I want to be able to offer a presence service
with ONE contact, which I assumed was one tuple, but don't care if there are
multiple tuples as long as they have the same contact URI.  That represents
the presence information of the presentity, full stop, including all of the
services it might support.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hisham Khartabil | 1 Feb 2005 19:34
Picon

Re: Presence data model: <device-id> in <tuple>


On Jan 30, 2005, at 1:40 PM, Goix Walter wrote:

> Krisztian,
>
> The examples in the presence data model draft identify <device-id> as 
> an element under <tuple>, but that's probably what you had in mind.
> However, I don't clearly see the rationale for multiple <device-id> 
> within a single <tuple>. Multiple devices for the same presentity may 
> offer exactly the same service, but they probably would need no 
> <contact> element to get the ability to be merged into a single 
> <tuple> at the server. In that case, if one device updates its <tuple> 
> inserting a <contact> element (max 1 in PIDF <tuple>), then both 
> tuples will need to be separated again. Same if another property of a 
> single device <tuple> is updated. I personally see more complications 
> than benefits allowing multiple <device-id> per <tuple>. Is there a 
> real requirement for such an optimization?

Think of it as multiple PUAs publishing tuples about the same service, 
and placing the AoR as the contact. The compositor may decide to merge 
those tuples, it is nice, but maybe not useful, for the watcher to see 
that this service is available on multiple devices.

/Hisham

>
> I agree that no namespace nor schema is defined for this extension. 
> Maybe the following declaration could be used:
>
>        <xs:element name="device-id" type="tns:anyURI" minOccurs="0"/>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane