Subject: RE: [Simple] Comments on PUBLISH

From: "Brian Stucker" <[email-masked]>
Date: Thu, 18 Jul 2002 13:09:48 -0500

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
> 
> 
> 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.

I'll let Jonathan answer that one..

> 
> 
> 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.

The idea here is that GeoLoc, if it so wished, could use the PUBLISH method
to update a presence server. I do not believe that the intent was to provide
EVERY way of publishing presence information via this draft, but a single,
standardizable approach that covers off as much ground as possible without
becoming overly complex. For instance, the compositor can still use
registration information to build the presence document. PUBLISH is simply
one tentacle feeding the octopus.

> 
> 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.

The header is optional. Some compositor functions may want more information
about what to do with the message body,  where the contents of the message
body can't easily convey what is intended. You could put the CPIM-PIDF tuple
id here if you liked, or leave it totally off.

> 
> 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.

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

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

> 
> 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.

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Jul 2002 11:29:59 -0500

> I'll let Jonathan answer that one..

I'm not Jonathan, nor do I play him on TV--but I will jump in anyway: 
Isn't that what the proposed ptype header is for?

> The idea here is that GeoLoc, if it so wished, could use the PUBLISH 
> method to update a presence server. I do not believe that the intent was 
> to provide EVERY way of publishing presence information via this draft, 
> but a single, standardizable approach that covers off as much ground as 
> possible without becoming overly complex. For instance, the compositor 
> can still use registration information to build the presence document. 
> PUBLISH is simply one tentacle feeding the octopus.

Certainly, the compositor is not limited to using PUBLISH. We are just 
not in the business of standardizing all methods a compositor can choose 
to use. The compositor might periodically query a geoloc server. Or 
maybe someone builds a geoloc server to PUBLISH adapter. As long as the 
compositor has enough information to make policy decisions on how to 
compose the input, it could be anything.

>  > thought the presentity URI would be used for that purpose.

The compositor decides whether the input should be composed or not, 
based on it's local policy for the "mobile" slot.

> The header is optional. Some compositor functions may want more 
> information about what to do with the message body,  where the contents 
> of the message body can't easily convey what is intended. You could put 
> the CPIM-PIDF tuple id here if you liked, or leave it totally off.
> 
>  >
> 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.
> 
>  >
> A'la subscription-state. Expires is confusing. Does it mean when the 
> message itself expires, or the content of the message?
> 
>  >
> 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.
> 
>  >
>  > Regards,
>  > Hisham