Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt

["Paul E. Jones" <[e-mail]>]

Adam,

 

The intent was to register a new capability and the registration appears with sip. prepended in the I-D.  What I’m missing is the message apparently sent by Paul K. regarding usage of that new tag in the contact header.  Does it require a +sip. or can we use sip.?  Is sip. stripped or not?  Reading page 7, it seems to suggest that tags that are not the “base tags” (those defined and enumerated on page 7) sip. cannot be stripped and a + sign prepended.  I may not be reading that correctly, thus the reason for the question below.

 

The broader issue is why we propose the introduction of this feature tag.  We’re not trying to “jump to a broken, semantic-free mechanism.”  The intent is to define a user agent capability and, more specifically, a feature tag.  The intent is to introduce something similar to those defined in RFC 3840.  Just as a device might be mobile, or a device might do video, we wanted something to indicate that a device has an immersive quality.  Why is sip.class defined to indicate that a device is in a business setting or personal setting?  With whatever logic was applied there, I would think specifying that a device is classified as “immersive” or not should apply.

 

The issue is that the IETF has defined the car (RFC 3840) into which we wish to install a radio, but folks are suggesting that we’re taking the wrong approach because the car isn’t actually a car, but a horse drawn carriage without electrical power and therefore impossible to support a radio.  Or, perhaps RFC 3840 is a defective Pinto that needs to be recalled?

 

You’re a smart fellow.  You understand the idea behind classifying a device as “immersive”.  There’s no magic to this, one does not need a voluminous document to convey the idea, nor are we trying to invent something that is out in left field that warrants such an elaborate document.  As with all of the other very short registrations appearing in RFC 3840, we merely propose to register a “sip.immersive” tag so that we can know when a device registers that it is an “immersive” device.  When the device calls another device, it can indicate via the Accept-Contact and Reject-Contact headers its preferences for communicating with another device that is classified as “immersive”.

 

The definition of immersive might be in question;  a portion of the definition for Telepresence could be used.  Telepresence brings with it much more than the immersive quality, as I mentioned before.  We could work to define “immersive” if that was the only concern, but I don’t think that is the issue.

 

I’m certainly open to suggestions for how this should be accomplished.  If this absolutely does not fit within the RFC 3840 framework, then I can accept the fact that I do not understand the point of RFC 3840.

 

Paul

 

From: Adam Roach [mailto:[e-mail]] 
Sent: Tuesday, March 13, 2012 1:12 AM
To: Paul E. Jones
Cc: Worley, Dale R (Dale); Glen Lavers (glavers); <[e-mail]>
Subject: Re: [dispatch] draft-lavers-sipcore-immersive-capability-00.txt

 

On Mar 12, 2012, at 20:05, "Paul E. Jones" <[e-mail]> wrote:

Syntactically, the "immersive" tag is allowed per RFC 3261 syntax.  Per RFC
3640, it seemed to suggest +sip was needed, but it was not clear how one can
define new "base" tags that do not require +sip.  So, there is no
possibility for introducing new base tags -- ever?

 

 

You can define new parameters, sure. But they aren't capability tags without the +sip.xxx syntax. You seem to think you want to define a capability. If that turns out to be the case, you'll need the +sip prefix.

 

Now, I personally think you have jumped to a broken, semantic-free mechanism to satisfy implied and vaguely defined requirements, rather than taking the more straightforward route of coming to the WG with solid, clear requirements, and soliciting input on reasonable mechanisms for meeting those requirements. The discussion around syntax of capability tags is like arguing over whether the car you've specified should have pin stripes, rather than discussing the broader issue of whether a car is actually the best tool for cooking pancakes.

 

Your requirements are probably valid, and it would be good to have them stated in a clear and exhaustive fashion. Your proposed mechanism, however, is misguided.

 

/a