Subject: [Sip] Policy to register media feature tags

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Mar 2009 12:47:27 +0200

Folks,

as you know, RFC 3840 specifies how to indicate UA's capabilities using
media feature tags. Section 12.1 of RFC 3840 creates the SIP Media
Feature Tag Registration Tree. Media feature tags applicable to SIP are
registered in this tree.

http://www.ietf.org/rfc/rfc3840.txt

RFC 2506 defines the global tree to register feature tags. Section 3.1.2
of RFC 2506 says: "A registration may be proposed for the global tree by
anyone who has the need to allow for communication on a particular
capability or preference".

http://www.ietf.org/rfc/rfc2506.txt

The currently registered feature tags in both the SIP and the global
trees can be found at:

http://www.iana.org/assignments/media-feature-tags

As you can see, the only three feature tags registered in the global
tree come from 3GPP.

The issue we are facing is that the SIP and the global trees have
different registration policies. The SIP registry requires an RFC
defining the feature tag while the global tree only requires an expert
review.

Now, 3GPP would like to register two new feature tags:  g.3gpp.icsi-ref,
g.3gpp.iari-ref

This is the description of how these feature tags will be used:

"Each value of the Application Reference media feature-tag indicates the
software applications supported by the agent. The values for this tag
equal the IMS communication Service Identifier (ICSI) and IMS
Application Reference Identifier (IARI) values supported by
the agent. The Application Reference media feature tag is
defined to fulfil the requirements for forking to an appropriate UE when
multiple UEs are registered and dispatch to an appropriate application
within the UE based upon the IMS communication Service Identifier
(ICSI) and IMS Application Reference Identifier (IARI) values as
stated in 3GPP TS 23.228.  Multiple tag-values can be included in the
Application Reference media feature-tag."

The expert reviewer indicated that this tags will not contain simple
features but rather more complex services, or feature sets, or
application logic (pick your favorite term). Therefore, he did not find
it appropriate to register them in the global tree. He suggested that
RFC 2506 is amended so that it covers this type of more complex features.

However, before going down that path, I would like to get comments from
the SIP community. The underlying issue is that we need to decide which
policy we want to apply to these types of registrations in SIP.

1) We decide that an RFC is always needed. Then, we can just use the SIP
registry. We would probably need to clarify or to stress somewhere that
the global tree is not appropriate for SIP tags.

2) We decide that an expert review is good enough. Then we would
probably need to amend RFC 2506 or RFC 3840 to reflect this.

Comments are welcome.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Mar 2009 09:41:48 -0400

Some issues just never go away. :-(

This seems to be a resurection of issues that first surfaced during the 
initial discussions of extended presence status many years ago. And it 
also harks back to discussions last year or the year before about 
communication service identifiers and application service identifiers.

The problem is one of openness. Specifically, do you have to be "part of 
the club" in order to properly interoperate with a device that uses 
these identifiers to identify its preferences or capabilities.

On one side were those who wanted capabilities and preferences to be 
stated in terms of feature tags that are well known and orthogonal. On 
the other side were those who prefer to associate arbitrary names to 
collections of features and then negotiate on the basis of the names of 
those collections.

Using the latter approach its possible that interoperation will fail 
because the parties don't share a common name for a collection of 
features even though they both possess the necessary features to 
interoperate.

I don't have a problem with independent groups defining new feature 
tags, as long as they are primitive and orthogonal to existing ones. But 
I do have a problem with defining feature tags that identify collections 
of features, especially when the mapping from the identifier to the 
collection of features is not public.

The bottom line is that I think this sort of thing needs to be thrashed 
out within the sip community. So I think the RFC process is the right 
process.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 21 Mar 2009 00:22:09 +0100

Responses inline...

/Hans Erik

Paul Kyzivat wrote:
> collections of features and then negotiate on the basis of the names 
> of those collections.
>
That is a feature. This interoperability "problem" only occurs when the 
originating party includes the header field parameters "require" and 
"explicit" in the Accept-Contact header field containing the feature 
tag. In this case the failure of the call when not all of the receiving  
UA's support  the feature is intended!
> tags, as long as they are primitive and orthogonal to existing ones. 
> But I do have a problem with defining feature tags that identify 
> collections of features, especially when the mapping from the 
> identifier to the collection of features is not public.
Well who is going to determine what can be called a feature and what not.
I also like to see where this principle is documented to apply to the 
global tree.
>
> The bottom line is that I think this sort of thing needs to be 
> thrashed out within the sip community. So I think the RFC process is 
> the right process.
I think that bending the rules because some SIP people don't like on how 
other organisations are applying SIP in their solutions will alieanate 
those SIP users from that same SIP community. So I seriously hope we 
will not go down that path.

/Hans Erik

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 09:26:23 -0400

Inline...

Hans Erik van Elburg wrote:
> That is a feature.

*what* is a feature?

> This interoperability "problem" only occurs when the 

Lets get tangible about this. (This is retracing old ground, but people 
sometimes have short memories.)

Suppose Alice calls Bob. Alice has the latest and greatest 3gpp phone 
with the capability to make audio/video calls, and would prefer to do so 
if possible. Bob has an open source softphone running on his PC. It is 
fully capable of audio/video operation using a wide source of codecs. He 
also has a plain vanilla audio phone registered to the same AOR.

Alice's phone will send an invite with offer containing audio and video 
media. It can also include callerprefs to bias the selection of device 
in favor of one that will support audio and video. It could do so a 
variety of different ways:
- indicate preference for audio and video
- indicate preference for the 3gpp "videophone" feature.
- indicate preference for audio, video, *and* 3gpp "videophone"

Assuming none of these *require* these features, the first and the last 
will both bias towards the softphone and result in an audio/video call. 
The middle will probably cause both of bob's phones to ring and 
audio/video will result if he happens to answer the softphone.

The situation is worse if Alice *requires* both audio and video, and as 
a result *requires* the 3gpp videophone feature.

The problem is one of orthogonality. the features should all be 
orthogonal to one another. If "3gpp videophone" encompasses "audio, 
video, and the 3gpp videophone look and feel", then it isn't orthogonal 
to the existing audio and video feature tags. If it only represents a 
preference for whatever extra goodies are provided by 3gpp over and 
above audio and video, then it may be a reasonable feature tag.

(Note that I have no knowledge of how 3gpp intends to name an use 
features. I'm just exploring the possibilities.)

> I also like to see where this principle is documented to apply to the 

IMO it was probably a mistake to use the existing feature tag mechanism 
for callee caps in the first place. While there are some simmilarities, 
the intentions are quite different. But we are where we are.

I don't know if we can impose additional rules on the global tree or 
not. I expect that imposing an orthogonality constraint might not be so 
controversial, and so *might* be possible. But the challenge may be in 
*defining* orthogonality in an application-independent way. It would be 
easier to do that in the context of sip, though still not trivial.

> will not go down that path.

Lets see what others say.

IMO its important that those other communities don't use this mechanism 
to erect more walls around their garden.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 23 Mar 2009 18:49:33 +0100

There is no rule stating that requiring "audio" and "video" will imply that
you also require one of the new tags. In that sense these tags are
completely orthogonal.

If the caller adds "require" header field parameter then it is a consequence
of the callerpreferences processing that some calls could fail that would
otherwise have succeeded. If the caller added this, then this must have been
its intention. That is the *feature* that RFC3841 provides to the caller.
The 3gpp specification does not say that one has to use "require" header
field parameter, it even warns that this might hamper interoperability.

So I think your following sentence was a fair analysis of how the newly
proposed tags are actually used/should be judged: "If it only represents a
preference for whatever extra goodies are provided by 3gpp over and above
audio and video, then it may be a reasonable feature tag."

/Hans Erik van Elburg

On Mon, Mar 23, 2009 at 2:26 PM, Paul Kyzivat <[email-masked]> wrote:

>>> stated in terms of feature tags that are well known and orthogonal. On the
>>> other side were those who prefer to associate arbitrary names to collections
>>> of features and then negotiate on the basis of the names of those
>>> collections.
>>>
>>> because the parties don't share a common name for a collection of features
>>> even though they both possess the necessary features to interoperate.
>>>
>> That is a feature.
>>
>
> *what* is a feature?
>
>  This interoperability "problem" only occurs when the originating party
>> includes the header field parameters "require" and "explicit" in the
>> Accept-Contact header field containing the feature tag. In this case the
>> failure of the call when not all of the receiving  UA's support  the feature
>> is intended!
>>
>
> Suppose Alice calls Bob. Alice has the latest and greatest 3gpp phone with
> the capability to make audio/video calls, and would prefer to do so if
> possible. Bob has an open source softphone running on his PC. It is fully
> capable of audio/video operation using a wide source of codecs. He also has
> a plain vanilla audio phone registered to the same AOR.
>
> media. It can also include callerprefs to bias the selection of device in
> favor of one that will support audio and video. It could do so a variety of
> different ways:
> will both bias towards the softphone and result in an audio/video call. The
> middle will probably cause both of bob's phones to ring and audio/video will
> result if he happens to answer the softphone.
>
> The situation is worse if Alice *requires* both audio and video, and as a
> result *requires* the 3gpp videophone feature.
>
> The problem is one of orthogonality. the features should all be orthogonal
> to one another. If "3gpp videophone" encompasses "audio, video, and the 3gpp
> videophone look and feel", then it isn't orthogonal to the existing audio
> and video feature tags. If it only represents a preference for whatever
> extra goodies are provided by 3gpp over and above audio and video, then it
> may be a reasonable feature tag.
>
> (Note that I have no knowledge of how 3gpp intends to name an use features.
> I'm just exploring the possibilities.)
>
>  I don't have a problem with independent groups defining new feature tags,
>>> as long as they are primitive and orthogonal to existing ones. But I do have
>>> a problem with defining feature tags that identify collections of features,
>>> especially when the mapping from the identifier to the collection of
>>> features is not public.
>>>
> IMO it was probably a mistake to use the existing feature tag mechanism for
> callee caps in the first place. While there are some simmilarities, the
> intentions are quite different. But we are where we are.
>
> I don't know if we can impose additional rules on the global tree or not. I
> expect that imposing an orthogonality constraint might not be so
>> other organisations are applying SIP in their solutions will alieanate those
>> SIP users from that same SIP community. So I seriously hope we will not go
>> down that path.
>>
>
> IMO its important that those other communities don't use this mechanism to
> erect more walls around their garden.
>
>        Thanks,
>        Paul
>
>  /Hans Erik

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 15:54:02 -0400

Hans Erik van Elburg wrote:
> There is no rule stating that requiring "audio" and "video" will imply 
> that you also require one of the new tags. In that sense these tags are 
> completely orthogonal.

Its good to hear that. While I had no specifics, I had hints to the 
contrary. I guess those were wrong.

> If the caller adds "require" header field parameter then it is a 
> consequence of the callerpreferences processing that some calls could 
> fail that would otherwise have succeeded. If the caller added this, then 
> this must have been its intention. That is the *feature* that RFC3841 
> provides to the caller. The 3gpp specification does not say that one has 
> to use "require" header field parameter, it even warns that this might 
> hamper interoperability.
> 
> proposed tags are actually used/should be judged: "If it only represents 
> a preference for whatever extra goodies are provided by 3gpp over and 
> above audio and video, then it may be a reasonable feature tag."

If that is the intent, then I am reassured.

Presumably the end user isn't actually selecting callerprefs. Rather the 
end user is just pushing a button on the phone to initiate a call, and 
some application on the phone is deciding what callerprefs to use.

So in the end it will be a question of whether the app constructs the 
call to maximize interop, or not.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> 
> On Mon, Mar 23, 2009 at 2:26 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Inline...
> 
> 
>             On one side were those who wanted capabilities and
>             preferences to be stated in terms of feature tags that are
>             well known and orthogonal. On the other side were those who
>             prefer to associate arbitrary names to collections of
>             features and then negotiate on the basis of the names of
>             those collections.
> 
>             Using the latter approach its possible that interoperation
>             will fail because the parties don't share a common name for
>             a collection of features even though they both possess the
>             necessary features to interoperate.
> 
>         That is a feature.
> 
> 
>     *what* is a feature?
> 
> 
>         This interoperability "problem" only occurs when the originating
>         party includes the header field parameters "require" and
>         "explicit" in the Accept-Contact header field containing the
>         feature tag. In this case the failure of the call when not all
>         of the receiving  UA's support  the feature is intended!
> 
> 
>     Lets get tangible about this. (This is retracing old ground, but
>     people sometimes have short memories.)
> 
>     Suppose Alice calls Bob. Alice has the latest and greatest 3gpp
>     phone with the capability to make audio/video calls, and would
>     prefer to do so if possible. Bob has an open source softphone
>     running on his PC. It is fully capable of audio/video operation
>     using a wide source of codecs. He also has a plain vanilla audio
>     phone registered to the same AOR.
> 
>     Alice's phone will send an invite with offer containing audio and
>     video media. It can also include callerprefs to bias the selection
>     of device in favor of one that will support audio and video. It
>     could do so a variety of different ways:
>     Assuming none of these *require* these features, the first and the
>     last will both bias towards the softphone and result in an
>     audio/video call. The middle will probably cause both of bob's
>     phones to ring and audio/video will result if he happens to answer
>     the softphone.
> 
>     The situation is worse if Alice *requires* both audio and video, and
>     as a result *requires* the 3gpp videophone feature.
> 
>     video, and the 3gpp videophone look and feel", then it isn't
>     orthogonal to the existing audio and video feature tags. If it only
>     represents a preference for whatever extra goodies are provided by
>     3gpp over and above audio and video, then it may be a reasonable
>     feature tag.
> 
>             I don't have a problem with independent groups defining new
>             feature tags, as long as they are primitive and orthogonal
>             to existing ones. But I do have a problem with defining
>             feature tags that identify collections of features,
>             especially when the mapping from the identifier to the
>         I also like to see where this principle is documented to apply
>         to the global tree.
> 
> 
>     IMO it was probably a mistake to use the existing feature tag
>     mechanism for callee caps in the first place. While there are some
>     simmilarities, the intentions are quite different. But we are where
>     we are.
> 
>     not. I expect that imposing an orthogonality constraint might not be
>     so controversial, and so *might* be possible. But the challenge may
>     be in *defining* orthogonality in an application-independent way. It
>     would be easier to do that in the context of sip, though still not
>     trivial.
> 
> 
>             The bottom line is that I think this sort of thing needs to
>             be thrashed out within the sip community. So I think the RFC
>             process is the right process.
> 
>         I think that bending the rules because some SIP people don't
>         like on how other organisations are applying SIP in their
>         solutions will alieanate those SIP users from that same SIP
>         community. So I seriously hope we will not go down that path.
> 
> 
>     IMO its important that those other communities don't use this
>     mechanism to erect more walls around their garden.
> 
>            Thanks,
>            Paul
> 
>         /Hans Erik
> 
>         Use [email-masked]
>         <mailto:[email-masked]> for questions on
>         current sip
>         Use [email-masked] <mailto:[email-masked]> for new
>         developments on the application of sip
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Mar 2009 10:14:59 -0400

Atle Monrad wrote:
> Paul 
> 
> For you information, the tags that 3gpp have specified and registered
> are described in publicly available 3GPP specifications which are
> referenced from the IANA registration. The same apply for the three tags
> that are in the pipeline. The reason for this is to secure openness and
> operability for vendors that want to support certain 3gpp-specific
> capabilities.
> 
> 3GPP would like to get all tags registered by IANA in order to secure
> that the tags are public and thereby the reference to the specifications
> where this particular 3GPP-functionality is specified is publicly
> available. 

I agree that is a good thing.

> To communicate these tags e-2-e is needed to support certain
> 3gpp-capabilities, and I do not really see the linkage towards you
> statement "On the other side were those who prefer to associate
> arbitrary names to collections of features and then negotiate on the
> basis of the names of those collections."

I will take that statement back as being based only on old impressions, 
not on real facts.

BUT, I still think there is reason to have *some* process to determine 
when something is a new independent feature, orthogonal to existing 
features, vs. one that turns out to overlap or conflict with existing 
features.

For instance, I went and looked up the 3gpp tags that have already been 
registered. I found the following in the registration:

   g.3gpp.smsip:
   This feature-tag indicates that the device is capable of accepting
   SMS messages via SIP as specified by ETSI TS 124 341.

Then I went and looked at ETSI TS 124 341, and found:

> 5.3.3.4 Delivering a short message in a SIP MESSAGE request
> 
> If a short message is received from the SMS-GMSC, the IP-SM-GW shall 
> extract the IMSI of the SM-over-IP receiver from the received message. 
> Then the IP-SM-GW shall obtain a corresponding public user identity and 
> deliver a SIP MESSAGE request with the following information:
> 
> a) the Request-URI, which shall contain a public user identity of the 
> SM-over-IP receiver;
> 
> b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip" 
> parameter and the "explicit" and "require" tags according to RFC 3841 
> [17];
> 
> Editor's Note: It is FFS whether the media feature tag value will be 
> hard coded or it will be an operator specific value distributed as part 
> of the service provisioning process.
> 
> c) the Request-Disposition header which shall contain the "no-fork" 
> directive;
> 
> d) the Content-Type header which shall contain 
> "application/vnd.3gpp.sms"; and
> 
> e) the body of the request which shall contain an RP-DATA message as 
> defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS 
> user information encoded as specified in 3GPP TS 23.040 [3].

 From a practical perspective, an SMS is pretty much equivalent to a 
MESSAGE message. Normally it contains *text*, and could be delivered in 
a basic MESSAGE with a body type of text/plain. In that form it could be 
received by anything that can handle a basic MESSAGE message.

Yet the above turns the SMS into a *different* feature, that will *only* 
be delivered to UAs that support that unique, but non-orthogonal, feature.

Even if SMS's aren't always just text, there are models to handle that 
more openly. For instance, multipart/alternative can be used to 
represent the message as text for those who only understand text, and as 
something richer for those who are capable of understanding that.

My point is not to harp on this feature in particular, but only to use 
it as an example. If there were some discussion about new feature tags, 
of whether they are unique or could be factored some other way in order 
to coexist better with existing features, then the potential for interop 
would be improved.

	Thanks,
	Paul

> Hope this clarifies
> 
> Regards
> /atle
> ______
> 
> Atle Monrad
> Standardisation
> 
> ST-Ericsson
> Product Group Mobile Platforms
>  
> Televeien 1
> N-4820, Grimstad
> Norway
> www.stericsson.com
> 
>  
> Office: +47 37 29 30 40
> Mobile: +47 45 41 06 65
> Fax: +47 37 04 23 70
> Email: [email-masked]
> 
> 	
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or distribution
> is prohibited. If you believe this message has been sent to you in
> error, please notify the sender by replying to this transmission and
> delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption,
> interception, unauthorized amendment, tampering and viruses, and we only
> send and receive emails on the basis that we are not liable for any such
> corruption, interception, amendment, tampering or viruses or any
> consequences thereof.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: 20. mars 2009 14:42
> To: Gonzalo Camarillo
> Cc: sip
> Subject: Re: [Sip] Policy to register media feature tags
> 
>> as you know, RFC 3840 specifies how to indicate UA's capabilities 
>> using media feature tags. Section 12.1 of RFC 3840 creates the SIP 
>> Media Feature Tag Registration Tree. Media feature tags applicable to 
>> SIP are registered in this tree.
>>
>> RFC 2506 defines the global tree to register feature tags. Section 
>> 3.1.2 of RFC 2506 says: "A registration may be proposed for the global
> 
>> tree by anyone who has the need to allow for communication on a 
>> particular capability or preference".
>>
>> Now, 3GPP would like to register two new feature tags:  
>> g.3gpp.icsi-ref, g.3gpp.iari-ref
>>
>> "Each value of the Application Reference media feature-tag indicates 
>> the software applications supported by the agent. The values for this 
>> tag equal the IMS communication Service Identifier (ICSI) and IMS 
>> Application Reference Identifier (IARI) values supported by the agent.
> 
>> The Application Reference media feature tag is defined to fulfil the 
>> requirements for forking to an appropriate UE when multiple UEs are 
>> registered and dispatch to an appropriate application within the UE 
>> based upon the IMS communication Service Identifier
>> application logic (pick your favorite term). Therefore, he did not 
>> find it appropriate to register them in the global tree. He suggested 
>> that RFC 2506 is amended so that it covers this type of more complex
> features.
>> However, before going down that path, I would like to get comments 
>> from the SIP community. The underlying issue is that we need to decide
> 
>> which policy we want to apply to these types of registrations in SIP.
>>
>> 1) We decide that an RFC is always needed. Then, we can just use the 
>> SIP registry. We would probably need to clarify or to stress somewhere
> 
>> that the global tree is not appropriate for SIP tags.
>>
>> This list is for NEW development of the core SIP Protocol Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments on the application of sip
>>
> This list is for NEW development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
>

---

From: "Atle Monrad" <[email-masked]>
Date: Tue, 24 Mar 2009 10:57:27 +0100

Hello 

To use one registration policy for all kind of feature tags may be a
"one size fits all" policy that in my view can lead to unnecessary
bottlenecks and delays. Personally I find it useful how RFC 2506
describe various mechanisms for registration of feature tags, and think
the current approach where a feature tag can be specified within one
organization and subsequently registered by IANA works well and is a
useful approach. At least it worked well for the first tags... 

Similar ergistration is also performed for other parameters from IANA,
and 3GPP has also "registration procedures" with other organizations as
GSMA, TISPAN and OMA for various other parameters as well. In some cases
the registration is made by 3GPP and in some cases the registration is
made by other organisations. Who act as registrar depends on who "owns"
the basic functionality of the parameter. Technical discussions are
often held to find a solution, but when the technical discussions are
held and a solution is chosen, the registration process is done to
register and not to re-open the discussion. 

3GPP has three feature tags described in 3GPP specifications and
registered in the global tree and three more feature tags described in
3GPP specifications waiting for similar registrations by IANA. It might
be useful to distinguish between the possible need for changing the
process for registration of future tags and performing registration of
tags that are in operation only missing the formal registration. I would
assume that the current process is in operation until a new registration
policy is available and agreed.

Regards
Atle Monrad 
3GPP CT1 Chairman
______

Atle Monrad
Standardisation

ST-Ericsson
 
Televeien 1
N-4820, Grimstad
Norway
www.stericsson.com

Office: +47 37 29 30 40
Mobile: +47 45 41 06 65
Fax: +47 37 04 23 70

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gonzalo Camarillo
Sent: 20. mars 2009 11:47
To: sip
Subject: [Sip] Policy to register media feature tags

Folks,

(ICSI) and IMS Application Reference Identifier (IARI) values as stated
in 3GPP TS 23.228.  Multiple tag-values can be included in the

RFC 2506 is amended so that it covers this type of more complex
features.

Comments are welcome.

Thanks,

Gonzalo

---

From: "Atle Monrad" <[email-masked]>
Date: Tue, 24 Mar 2009 11:36:39 +0100

Paul 

Hope this clarifies

Regards
/atle
______

Atle Monrad
Standardisation

ST-Ericsson
 
Televeien 1
N-4820, Grimstad
Norway
www.stericsson.com

Office: +47 37 29 30 40
Mobile: +47 45 41 06 65
Fax: +47 37 04 23 70

-----Original Message-----

	Thanks,
	Paul

features.