Re: [Sip] Comments on draft-ietf-sip-callee-caps-01

[Jonathan Rosenberg <[e-mail]>]

inline.

Drage, Keith (Keith) wrote:

> I have the following comments and questions on the above draft:
> 
> 1)	Given an indication of support of a specific feature, is there a
> requirement to indicate all other features supported that can be
> indicated using the protocol.

No. The draft doesnt provide strict guidannce on which exact 
parameters to include, except to say that it should provide as much 
information as it can.

> I currently can find no words to
> indicate this one way or another. My preference would be to allow
> support only of those feature tags that an implementation considers
> "useful" for its implementation, but I would be concerned if the
> implementor of a peer entity took the opposite approach and
> insisted that my implementation was non-conformant for this reason.
> As one example, an "isfocus" is probably also an "automata". Is
> there a need to indicate both?

isfocus does imply automata in this case, yes. However, they are 
different things. I dont want to introduce into the spec implicit 
capabilities; that is, the presence of one capability implies another. 
I think thats dangerous.

In terms of your original question, I do not see a need for further 
guidance on what information to include, beyond what the spec says 
already. Are there specific words which you think people will use to 
declare implementations non-compliant because they omitted information?


> 
> 2)	I note that this extension uses the same option-tag as the
> callerprefs extension, i.e. "pref". Apart from using the same
> option-tag, I see no dependency between the two extensions, and it
> would appear completely valid for an implementation to support one
> extension and not the other. I would therefore have expected two
> completely different option-tags, one for each extension. Is there
> a reason for the option-tag reuse, apart from the history that
> these two extensions were originally one extension.

No, the history is the main reason.

I think it does make sense to have them separate. That would require a 
change to caller prefs to define a new tag. Unfortunately, caller 
prefs has just been approved, and at this point I cannot issue a 
revision. Also, this is not a change that can be made during auth48, 
since IANA actions occur before auth48. Therefore, changing this would 
require some kind of special casing here, not exactly sure how. 
Honestly, I'm not sure its worth fixing, given its not a big deal.

So, I would prefer to just keep this as is.

> 
> 3)	Section 10.1 defines a number of feature tags relating to the
> support of media types. The text currently specifies that the use
> of these tags indicates "the device supports xxx as a media type".
> Surely in each case it would be more complete to state that "the
> device supports xxx as a media type, and the selection of that
> media type using SIP and SDP", assuming that that additional
> constraint applies.

This has been clarified in the -03 revision of the document. The 
audio, video, etc. attributes refer specifically to streaming media 
received via RTP or similar. It does not refer to support for bodies 
of those types in SIP messages.

> 
> 4)	Section 10.1.5 mentions floor control protocol as an example.
> Would it not be sensible to avoid using floor control protocols as
> an example until XCON have decided what protocol the floor control
> protocol is, and how its use is negotiated. While I guess this
> could be any floor control protocol, SIP people will automatically
> think XCON for conferences.

OK. I can say something else.

> 
> 5)	Section 10.2.4. Mobility feature. In the past we have had
> discussions about what this meant and whether it was useful. I
> thought in general the conclusion was that it wasn't particularly
> useful. It is certainly not useful if I don't understand what is
> meant by mobility. For example a 3GPP IMS user would be using a
> handset that would normally be regarded as mobile. However the
> mobility is supported entirely by the underlying layers, and SIP
> sees no mobility. 

Thats OK. These things dont need to refer to sip characteristics at all.

> The IP address and all other things remain static
> for the duration of a registration, even if the handset moves (I
> note that one of Gonzalo's drafts talks about session mobility only
> in the context of changing IP addresses). If I put my conference
> server on board an ocean liner, is it mobile or not? So if we keep
> this feature, can we have some more words to indicate what is a
> mobile UA, and what is a fixed one.

Its not really important that there is a really concise, mathematical 
kind of definition. We will always have devices which blur limits and 
make it hard to formulate a definition. I think all that really 
matters is that the user of the device consider that a "mobile 
device", such that if a user wishes to reach them on their mobile, 
thats the device that gets reached.


> 
> 6)	Section 10.2.2. Class. I wonder if there are sufficient values
> here. Will this go the way of the top level domain names, and we
> will need an class=organisation for those phones that are neither
> business or personal.

I think the business/personal distinction is pretty well understood. 
I'm not sure what you mean by organization. Did you mean that phones 
would register things like "class=dynamicsoft.com"?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip