[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] comments on draft-ietf-simple-rpid (long) - activity

Thanks for the extensive comments. Part of the problem with the document is that it has been sliced and re-diced several times so that remnants of earlier incarnations are still there. I'm removing the editorial items below; from my quick reading, they should be easy to fix.

More later. I think it would be easier to split this into several threads if there is discussion on any of the items.

This extension does not replace media negotiation mechanisms defined
   for SIP (e.g., SDP [8]), therefore media negotiation (e.g., choice of
   voice and video codecs) MUST be performed according to RFC 3264 [10].
This was a remnant when the capabilities stuff was still in the draft. It makes even less sense now.

This is an odd statement for this specification, especially as the first 


I dont think there are any capabilities defined in RPID. Also, nothing 

Another one...




Communities of interest such as a profession or an
   organization may define additional activity labels for their internal
   use.






If so, don't we introduce the possibility of name collisions? If you 
really want this, you might need to do something like:



org.dancers-of-america.square-dancing



i.e, us some kind of vendor prefix.



But, I'd rather not do that, since we introduce yet another namespace 
management when we have a fine one in the form of XML. I'd rather allow 
only values defined from the ietf controlled registry.


Agreed.






Depending on the presentity intent, all but the "available"
   indication can be used with either status OPEN or CLOSED.

   Available: The presentity is available for communication.




indeed - what is the difference between <available> and open?




I'm not sure this is useful; it was meant to allow inclusion of the 
'activity' even if there was no other activity to report.








Appointment: The presentity has a calendar appointment.







 Meeting: This activity category can often be generated automatically
      from a calendar.




what is the difference between these too?




A meeting is a sub-class of appointment; appointment includes my visit 
to the dentist and attending my son's soccer game.








In-transit: The presentity is riding in a vehicle, such as a car, but
      not steering. Alternatively, the presentity MAY offer more
      specific information.




how does one offer more specific information?



Steering.






Busy: User is busy, without further details.  This activity category
      would typically be indicated manually.






How does busy differ from closed? Also, I dont see a reason why it 
couldnt automatically be generated. For example, if I'm in a meeting.



I can be busy, but open to some kinds of communication from certain 
people. It just indicates that I'm probably not to be bothered with 
lengthy or can-wait communication.






Permanent-absence: Presentity will not return for the foreseeable
      future, e.g., because it is no longer working for the company.




what would this mean with open?




OPEN does seem unlikely here. I suppose if I have an answering service, 
this could happen.








and the time until which is element is expected to be valid.  The
   'from' time MUST be in the past, the 'until' time in the future
   relative to the publication of the presence information.






I think you need to be careful with the word "publication" here. If, 
right now, I publish a document saying that I'm in a meeting until 10pm, 
then at 11pm, the 'until' time is still in the future relative to the 
*publication* time, but not relative to the time at which the 
notification is sent. I think you need to say "transmission" and clarify 
that this includes either publication or notification.


How about relative to the 'timestamp' element?



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple