Subject: [Simple] Comments on PUBLISH

From: [email-masked]
Date: Mon, 8 Jul 2002 15:42:40 +0300

1. The concept of Input slots seems a bit vague. Does a slot represent entities that publish presence info of the same type, eg: geographic location? i.e. All devices that publish geographic location information fit into that slot? If so, why is a use device not a GeoLoc entity?

A User device can publish geographic location information as well as the user's availability for voice and IM, for example. How do slots work in that scenario?

Also, how does a Presence Compositor know which publication belongs to which slot?

Perhaps I miss understood this concept completely.

2. Document assumes that all presence publication is achieved using PUBLISH. That is not true. A example, as a matter of fact, is the GeoLoc.

3. PType header: If is described as useful for 2 things:

- the document that is being published is part of a larger composite document. How does PType here help? If PType is defined to be "mobile", how does that tell the compositor that it belongs to a larger composite document? I would have thought the presentity URI would be used for that purpose.

- The document that is being published will be applied to many components of the composed document. Please give me an example of this. I fail to understand how this could be done.

This is something for the PUBLISH body, not a SIP header.

4. PStream header: How does a header that looks like call-id guarantees correct sequencing of messages? Header like Date, and information in the message body seem like a much better way of sequencing.

5. PState Header: why is it defined that way? why not PExpires or just Expires?

6. I don't think its the PA who should decide how long a PUBLISH is valid for. How is that possible? I publish from my PC that's I'm available for IM for one hour, why would a PA override that?

Regards,
Hisham

---

From: [email-masked]
Date: Mon, 22 Jul 2002 13:09:45 +0300

-----Original Message-----
From: ext Brian Stucker [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 9:10 PM
To: Khartabil Hisham (NMP/Helsinki); [email-masked]
Subject: RE: [Simple] Comments on PUBLISH

Comments embedded within... 
> -----Original Message----- 
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, July 08, 2002 7:43 AM 
> To: [email-masked] 
> Subject: [Simple] Comments on PUBLISH 
> 
> 

> 
>> 4. PStream header: How does a header that looks like call-id 
>> guarantees correct sequencing of messages? Header like Date, 
>> and information in the message body seem like a much better 
>> way of sequencing. 
>Let's say I have two devices, and they faithfully put the date header in, as you suggest, but there's no easy way to figure out from the message content that the PUBLISH messages from these two
>sources are, in fact, from two sources. So, the result of that is to either require the clients to use the same callid/tags and keep bumping up the CSeq (ala the weak/brittle solution for
>REGISTER), or we give them an additional way to provide a token that the compositor can track against to correlate that this set of PUBLISH messages came from the same place, without getting into 
>tag/callid mayhem.
>

if a publisher has to remember the value of the PSteam header and still use CSeq for sequencing, then its the same weak/brittle solution. You might as well use the call-id header and save yourself the bandwidth. If the PSteam header carried a sequence number of its own, then I can understand its purpose, but I still think that this information is better carried in the body.

>A'la subscription-state. Expires is confusing. Does it mean when the message itself expires, or the content of the message?

This is what the PUBLISH draft has to document. Expires is method dependent as we all know.

> 
>> 6. I don't think its the PA who should decide how long a 
>> PUBLISH is valid for. How is that possible? I publish from my 
>> PC that's I'm available for IM for one hour, why would a PA 
>> override that? 
>The PA is the repository of this information, and as such needs to control how long it is responsible for such. You could apply the same logic to say that a registrar shouldn't limit the amount of >time that a contact is registered for. If the client wants to stay registered for 137 years, then so be it. Same goes for event subscriptions. A PUBLISH uses finite resources at the compositor,
>therefore, the compositor should have final word in how long it's willing to allow those resource to be used at one shot.

Ok, why is it a MUST then? How does the compositor tell the publisher that this publication is valid until you update it if the compositor doesn't care about how long the PUBLISH is valid for. Is Expires-header mandatory in PUBLISH request? If so, why?

Regards, 
Hisham 
> _______________________________________________ 
> simple mailing list 
> [email-masked] 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple 
>