Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05

From: [email-masked]
Date: Thu, 5 Sep 2002 19:31:11 +0300

Hi,

> For interop, PIDF says that for status value ranges that 
> extend <basic>
> (i.e. they imply some OPEN or CLOSED value), the <basic> 
> value must also
> be present. My suggestion for IM status values is to have a dictionary
> of values without necessitating an inherent OPEN/CLOSED property to
> avoid endless debate. As far as possible, values with the 
> same semantics
> should be reduced to one word (e.g. if there is a consensus 
> that 'away'
> and 'idle' are the same, then we only need one). But if there are
> objections, I see no major disadvantage with having a larger 
> dictionary
> within reason (e.g. if there is no consensus that 'dnd' and 'busy' are
> the same, say, then they could both be included and some people will
> interpret them as the same and others as different).

The reason why I initiated this thread on IMPP list was not to define
'away', 'idle', 'busy', etc. It was rather adding exact communication
means to tuples (like 'voice', 'video', 'game', etc.), which goes beyond
the contact's URI scheme. Currently if a tuple contains a contact, like:
<contact priority="1.0">sip:[email-masked]</contact>
its communication mean is 'sip:' which does not tell too much about the
presentity's capabilities & willingness whether he/she wants to use this
sip: contact for voice, video or chat. This might be a specific issue of
SIP URIs, therefore it was proposed to move the discussion to this list.

Paul also wrote a good summary about the issue on IMPP:

> The sip uri explicitly does not say anything about the media 
> it supports. That is negotiated via the exchange of SDP.
> 
> There is an ability when registering a contact address with a 
> sip registrar to specify capabilities of the addressed 
> endpoint, including the types of media it supports. But this 
> is represented as header parameters on the contact header 
> rather than as parameters of the sip url itself.
> 
> In pidf, the equivalent functionality could be achieved by 
> either adding extra parameters to the <contact> element, or 
> by adding new values to the <status> element.
> 
> Of course one possibility is to simply say it is up to the 
> presence client to use the sip address from the contact, 
> together with some sip messaging to discover the current 
> capabilities of the endpoint. But that sounds like a very bad 
> idea to me - you are essentially back to polling all buddies 
> for presence information. I think it is important for the 
> presence document to be able to represent what media the 
> contact is prepared to use, so that can be displayed for the 
> end user. (I want to be able to see at a glance whether you 
> are present for IM or Voice, or both.

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

---

From: "Adrian Bateman" <[email-masked]>
Date: Thu, 5 Sep 2002 18:30:20 +0100

> SIP URIs, therefore it was proposed to move the discussion to this
list.

I appreciate that but my interpretation of 

  SEP 02  Submission of SIMPLE PIDF profile to IESG for 
          publication as Proposed Standard 

from past discussions was with the application of PIDF to IM (SIMPLE is
also about IM over SIP is it not?). If media type is also a SIMPLE work
item then I see no reason why the two very similar efforts can't be
handled at the same time to help us move along.

Adrian.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Sep 2002 14:05:25 -0400

> handled at the same time to help us move along.

I don't know if addressing media type, or perhaps more generally addressing the application of PIDF to SIP in all its glory, is covered by this or any other work item of SIMPLE. Based on the feedback in impp, this is deemed the appropriate place to address it. 

I defer a decision on whether this requires a new work item to those with more understanding of IETF procedures.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Sep 2002 14:20:48 -0400

Paul Kyzivat wrote:
 >> SEP 02  Submission of SIMPLE PIDF profile to IESG for publication
 >> as Proposed Standard
 >>
 >> from past discussions was with the application of PIDF to IM
 >> (SIMPLE is also about IM over SIP is it not?). If media type is
 >> also a SIMPLE work item then I see no reason why the two very
 >> similar efforts can't be handled at the same time to help us move
 >> along.
 >
 >
 > I don't know if addressing media type, or perhaps more generally
 > addressing the application of PIDF to SIP in all its glory, is
 > covered by this or any other work item of SIMPLE. Based on the
 > feedback in impp, this is deemed the appropriate place to address it.

I think its reasonable to include it in the scope of the current work item.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Himanshoo Kumar Saxena <[email-masked]>
Date: Fri, 06 Sep 2002 10:22:36 +0800

Hi,

A simple question to confirm my understanding...

Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information.
Based on the duration in expires header field of A's subscription, till that time, A is considered online. In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended. So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline....
Is this understanding correct ?

Regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Shenzhen - 518000
P.R.China

---

From: Himanshoo Kumar Saxena <[email-masked]>
Date: Fri, 06 Sep 2002 10:38:55 +0800

Hi,

THis draft was supposed to expire on December 2000. Has it been updated or included in soem RFC. Is somebody updating this draft ?

regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Hua Dian R&D Center
4th floor,
Long Gang District
Shenzhen - 518000
P.R.China
Ph: +86-755-28788478(Off)
       +86-755-28767187(Res)
  ----- Original Message ----- 
  From: Jonathan Rosenberg 
  To: Paul Kyzivat 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Friday, September 06, 2002 2:20 AM
  Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05

  -Jonathan R.

---

From: Himanshoo Kumar Saxena <[email-masked]>
Date: Fri, 06 Sep 2002 11:17:45 +0800

Hi,

If a user client wants to REGISTER but also wants to provide some additional information like user Nick Name etc. then how can it be done ?

regards

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 02:40:12 -0400

This draft was abandoned long ago. The process of handling interactive 
authorization is through the watcherinfo specifications to inform the 
user that they need to make a decision:

http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-02.txt

followed by a setting of authorization policy for them. That can be done 
through wap/web. An explicit protocol for manipulating authorization is 
now on our charter; the requirements for it are documented in:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt

-Jonathan R.

Himanshoo Kumar Saxena wrote:
> Hi,
>  
> THis draft was supposed to expire on December 2000. Has it been updated 
> or included in soem RFC. Is somebody updating this draft ?
>  
> regards
>     *From:* Jonathan Rosenberg <mailto:[email-masked]>
>     *To:* Paul Kyzivat <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     *Sent:* Friday, September 06, 2002 2:20 AM
>     *Subject:* Re: [Simple] RE: Communication means in
>     draft-ietf-impp-cpim-pidf-05
> 
> 
> 
>     Paul Kyzivat wrote:
>      >
>      > Adrian Bateman wrote:
>      >
>     [email-masked]
>     <mailto:[email-masked]>                     FAX:   (973)
>     952-5050
>     [email-masked] <mailto:[email-masked]>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 10:43:01 -0400

REGISTER is for establishing an address binding so that a client can be 
reached for incoming requests. It is not a tool for provisioning 
information like name, nickname, street address, and so on. You will 
need to use provisioning techniques for that (web page, for example).

-Jonathan R.

Himanshoo Kumar Saxena wrote:
> Hi,
>  
> If a user client wants to REGISTER but also wants to provide some 
> additional information like user Nick Name etc. then how can it be done ?
>  
> regards