Paul,

Whoops! There is the same problem with LocationRejectReason and aliasesInconsistent--it also changed position between IGv2 and H.225.0v3.

I never did like H.323 IGs being normative. Too dangerous. If normative, IGs should only be used for clarification and true corrections, not for _any_ modifications no matter how innocuous they may seem. For H.324, IGs were not normative and merely somewhere to write down the things we were going to change in the _next_ version until the next version came out.

FWIW, Smith Micro skipped v2 and went straight from v1 to v3, so we use the Decided v3 syntax for ARJ and not the v2 syntax as modified by IGv2.

BTW, I didn't see this latest email from you on the implementers reflectors. In case we have a disjoint set of participants, you need to keep them in the loop, too.

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, October 04, 2000 2:19 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Error in H.323v3 ASN.1

Anatoli,

This is a difficult situation here: and we've been here before. I received e-mail from one company this morning that said they need the H.323v2 field, because they did use the Implementers Guide definitions.

Now, it appears that we have the same problem as we had with the TokenOID problem back in May 1999 where one published document contradicted another.

So, how can we resolve this issue? I've already concluded that, based on the number of vendors out there with H.323 products, we can't possibly contact them all and take a vote :-)

Without getting into specific details: at this point, 1 year after the published H.323v3 document, how much effort would it be to try to change the H.323v3 software you have deployed and how much of an impact would that have? Did you also pick up all of the other H.323v3 ASN.1 changes that have been made? See this file for a complete, updated ASN.1 for v3: http://www.packetizer.com/iptel/h323/h2250v3.asn. Of course, it does contain the error we're talking about here, but that is only because I copied the ASN.1 from the published v3 document and then modified it according to the Implementers Guide.

Paul

Paul,

I just checked, and we are shipping v3 EPs. I agree that there are probably many more v2 entities than v3 entities, and therefore if we have to break one, we should break the one which will have the least impact on the market.

To minimize the impact this will have on interoperability, however, let's don't simply move the reasons around. Instead, lets deprecate the current routeCallToSCN and aliasesInconsistent reasons using the following syntaxes in IGv3 and H.225.0v4.

Proposed IGv3 syntax

AdmissionRejectReason ::= CHOICE { calledPartyNotRegistered NULL, -- cannot translate address invalidPermission NULL, -- permission has expired requestDenied NULL, -- no bandwidth available undefinedReason NULL, callerNotRegistered NULL, routeCallToGatekeeper NULL, invalidEndpointIdentifier NULL, resourceUnavailable NULL, ..., securityDenial NULL, qosControlNotSupported NULL, incompleteAddress NULL,

-- changes start here: deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use callCapacityExceeded NULL, -- destination has exceeded call capacity aliasesInconsistent NULL, -- multiple aliases in request identify distinct people routeCallToSCN SEQUENCE OF PartyNumber }

Proposed H.225.0v4 syntax

AdmissionRejectReason ::= CHOICE { calledPartyNotRegistered NULL, -- cannot translate address invalidPermission NULL, -- permission has expired requestDenied NULL, -- no bandwidth available undefinedReason NULL, callerNotRegistered NULL, routeCallToGatekeeper NULL, invalidEndpointIdentifier NULL, resourceUnavailable NULL, ..., securityDenial NULL, qosControlNotSupported NULL, incompleteAddress NULL,

-- changes start here: deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use exceedsCallCapacity NULL, -- destination does not have the capacity for this call aliasesInconsistent NULL, -- multiple aliases in request identify distinct people routeCallToSCN SEQUENCE OF PartyNumber, collectDestination NULL, collectPIN NULL }

I assume we can change both because neither are Decided and these are true irreconcilable errors in the documents, correct? Here are the specifics: We rename the old reasons to "deprecate*", add the new ones after callCapacityExceeded/exceedsCallCapacity, and then in the text of IGv3 and H.225.0v4 say that the old ones shall not be transmitted and if received shall be treated like undefinedReason. Otherwise, a receiver would have to parse the AdmissionReject message differently depending on the version of the transmitter. We, Smith Micro, can actually do that with our ASN.1 parser but I'm guessing that most implementations cannot. Maybe we should even change the type of deprecatedRouteCallToSCN to NULL so that the ASN.1 PER parser would simply skip over the contents via the encapsulating open type. I know that our parser would do this. Would others?

v1 implementations won't have a problem, because they would ignore this reason, anyway, but we could encourage v2 implementations to treat aliasesInconsistent like undefinedReason since they won't know if it is aliasesInconsistent from a v2 EP or some other extended choice from a v3+ EP.

Paul Long Smith Micro Software, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

Paul,

I put together a spreadsheet to evaluate all possible combinations of fixes and versions. It's pretty small (15K), so I attached it.

You are right that there will be some v2 entities that expect to see the old aliasesInconsistent choice, but they will now only receive them from other v2 entities (compatible ones choices) or v3 entities that have not applied what I propose to be added to IGv3 (incompatible choices). The latter is simply broken, and there is nothing we can do to fix it, no matter which approach we take. A v2 entity will be no worse than a v1 entity in that it will receive a reject reason that it doesn't understand because it was added after v2, e.g., a new aliasesInconsistent. In this case, it should treat the reason as undefinedReason. This is the way unrecognized reasons and choices in general have always been treated.

Regarding v3, if we swap the choices in IGv3 and H.225.0v4 as you propose, "pre-fix" v3 entities like our EPs will definitely encounter decode errors--they will always be at risk. The same goes for v3 GKs. If a v3 GK transmits either of these pre-fix choices, the receiving "fixed" EP will encounter a decode error. On the other hand, the worse thing that can happen using my proposal is that an entity would treat these pre-fix choices as undefined reasons--a much better outcome.

We should also recommend that v2 GKs no longer send the old aliasesInconsistent reason. They should instead send undefinedReason. It is unfortunate that they would lose the ability to convey this particular info to the EP, but the alternative is risking a decode error and dropping the call.

I realize that my proposed fix of deprecating the two extant reasons is less elegant than simply switching them around in order to agree with v2. However, as you can see from the spreadsheet, the benefit of interoperability far outweighs this.

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, October 05, 2000 11:15 PM To: Paul Long; Mailing list for parties associated with ITU-T Study Group 16 Cc: h323implementors@imtc.org; h323implementors@pulver.com Subject: Re: Error in H.323v3 ASN.1

Paul,

The problem with this simpler approach to deprecating the fields is that there will still be v2 entities that expect to see the aliasesInconsistent field and there may be v3 entities out there that assume a different field is there and things will be broken between those endpoints.

Perhaps it might be less of an impact, though...

Paul

----- Original Message ----- From: "Paul Long" Plong@SMITHMICRO.COM To: "Mailing list for parties associated with ITU-T Study Group 16" ITU-SG16@mailbag.cps.intel.com Cc: h323implementors@imtc.org; h323implementors@pulver.com Sent: Thursday, October 05, 2000 2:08 PM Subject: RE: Error in H.323v3 ASN.1

Paul,

I just checked, and we are shipping v3 EPs. I agree that there are

probably

many more v2 entities than v3 entities, and therefore if we have to

break

one, we should break the one which will have the least impact on the

market.

To minimize the impact this will have on interoperability, however,

let's

don't simply move the reasons around. Instead, lets deprecate the

current

routeCallToSCN and aliasesInconsistent reasons using the following

syntaxes

in IGv3 and H.225.0v4.

Proposed IGv3 syntax

AdmissionRejectReason ::= CHOICE { calledPartyNotRegistered NULL, -- cannot translate address invalidPermission NULL, -- permission has expired requestDenied NULL, -- no bandwidth available undefinedReason NULL, callerNotRegistered NULL, routeCallToGatekeeper NULL, invalidEndpointIdentifier NULL, resourceUnavailable NULL, ..., securityDenial NULL, qosControlNotSupported NULL, incompleteAddress NULL,

-- changes start here: deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use callCapacityExceeded NULL, -- destination has exceeded call capacity aliasesInconsistent NULL, -- multiple aliases in request identify

distinct

people routeCallToSCN SEQUENCE OF PartyNumber }

Proposed H.225.0v4 syntax

AdmissionRejectReason ::= CHOICE { calledPartyNotRegistered NULL, -- cannot translate address invalidPermission NULL, -- permission has expired requestDenied NULL, -- no bandwidth available undefinedReason NULL, callerNotRegistered NULL, routeCallToGatekeeper NULL, invalidEndpointIdentifier NULL, resourceUnavailable NULL, ..., securityDenial NULL, qosControlNotSupported NULL, incompleteAddress NULL,

-- changes start here: deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use exceedsCallCapacity NULL, -- destination does not have the capacity

for

this call aliasesInconsistent NULL, -- multiple aliases in request identify

distinct

people routeCallToSCN SEQUENCE OF PartyNumber, collectDestination NULL, collectPIN NULL }

I assume we can change both because neither are Decided and these are

true

irreconcilable errors in the documents, correct? Here are the

specifics: We

rename the old reasons to "deprecate*", add the new ones after callCapacityExceeded/exceedsCallCapacity, and then in the text of IGv3

and

H.225.0v4 say that the old ones shall not be transmitted and if

received

shall be treated like undefinedReason. Otherwise, a receiver would

have to

parse the AdmissionReject message differently depending on the version

of

the transmitter. We, Smith Micro, can actually do that with our ASN.1

parser

but I'm guessing that most implementations cannot. Maybe we should

even

change the type of deprecatedRouteCallToSCN to NULL so that the ASN.1

PER

parser would simply skip over the contents via the encapsulating open

type.

I know that our parser would do this. Would others?

v1 implementations won't have a problem, because they would ignore

this

reason, anyway, but we could encourage v2 implementations to treat aliasesInconsistent like undefinedReason since they won't know if it

is

aliasesInconsistent from a v2 EP or some other extended choice from a

v3+

EP.

Paul Long Smith Micro Software, Inc.

Bancroft,

These components are in a CHOICE type, so the clause that you specify has nothing to do with our discussion. I think your response assumes they are in a SEQUENCE type.

Also, by "do not use," I meant that, upon receipt, these choices are to be semantically treated as another, generic choice, undefinedReason and that they are to no longer be transmitted. Again, these are CHOICE, not SEQUENCE components.

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Friday, October 06, 2000 4:17 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Error in H.323v3 ASN.1

On Thu, 5 Oct 2000, Paul Long wrote:

<snip>

Unless I am misunderstanding what you are saying, the "-- do not use" will not work if the receiver is using an earlier version in which the "-- do not use" type is defined, for it violates X.680 clause 24.14:

24.14 A value for a given extension addition type shall not be specified unless there are values specified for all extension addition types not marked OPTIONAL or DEFAULT that lie logically between the extension addition type and the extension root.

NOTE 1 -Where the type has grown from the extension root (version 1) through version 2 to version 3 by the addition of extension additions, the presence in an encoding of any addition from version 3 requires the presence of an encoding of all additions in version 2 that are not marked OPTIONAL or DEFAULT.

Omitting OPTIONAL and DEFAULT from an extension addition definition means that an extension addition value is mandatory in messages that are originated by an implementation in which such extension additions are defined, which implies that an encoding cannot have a missing mandatory extension addition value followed by any other component.

The only way that interoperability can be achieved here is by the older version H.225 spec being changed to add OPTIONAL to those items marked with "-- do not use". It will have no effect on the bits on the wire, other than to make such encodings valid.

------------------------------------------------------------------------ - Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

Paul,

If my understanding is as mentioned below, with all due respect, I wish to point out that this proposal will not work.

I assume you are proposing this because the H323v3 code is already sent out by some stack vendors but find it difficult to go to those customers and change thye stack. If I am correct, your proposal is that the H323v3 code that already shipped out will use the "erroneous" v3 spec. i.e the "routeCallToSCN SEQUENCE OF PartyNumber" parameter appearing first; but the new H323v3 code with your proposal has "deprecatedAliasesInconsistent NULL" first. i.e in the logical incresed ordering of the extension additions both take the same position (#3) in the choice. However, one is of type NULL and the other is of type SEQUENCE OF.

Let us say H.323v3 endpoint with erroneous spec use, encodes a message choosing the routeCallToSCN field (poistion #3 with type SEQUENCE OF), the new H.323v3 with your proposed change will attempt to decode that same field to a NULL type. As a result, all the subsequent decodings will be inconsistent based on how many elements were added in the SEQUENCE OF encoding. In this discussion, always remember that the parent type is a CHOICE. Hence there should be one and only one field should be present.

In my opinion, even well known ASN.1 decoders (not appropriate for me to mention names) will go crazy here when a message from H.323v3 EP with erroneous spec use sends a message to the EP using newly proposed spec.

o we have a compatibility problem between the erroneous H.323v3 endpoint and the endpoint using the proposed H.323v3 spec.

- Logan

Paul Long wrote:

Paul,

I just checked, and we are shipping v3 EPs. I agree that there are probably many more v2 entities than v3 entities, and therefore if we have to break one, we should break the one which will have the least impact on the market.

To minimize the impact this will have on interoperability, however, let's don't simply move the reasons around. Instead, lets deprecate the current routeCallToSCN and aliasesInconsistent reasons using the following syntaxes in IGv3 and H.225.0v4.

Proposed IGv3 syntax

AdmissionRejectReason ::= CHOICE { calledPartyNotRegistered NULL, -- cannot translate address invalidPermission NULL, -- permission has expired requestDenied NULL, -- no bandwidth available undefinedReason NULL, callerNotRegistered NULL, routeCallToGatekeeper NULL, invalidEndpointIdentifier NULL, resourceUnavailable NULL, ..., securityDenial NULL, qosControlNotSupported NULL, incompleteAddress NULL,

-- changes start here: deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use callCapacityExceeded NULL, -- destination has exceeded call capacity aliasesInconsistent NULL, -- multiple aliases in request identify distinct people routeCallToSCN SEQUENCE OF PartyNumber }

Proposed H.225.0v4 syntax

AdmissionRejectReason ::= CHOICE { calledPartyNotRegistered NULL, -- cannot translate address invalidPermission NULL, -- permission has expired requestDenied NULL, -- no bandwidth available undefinedReason NULL, callerNotRegistered NULL, routeCallToGatekeeper NULL, invalidEndpointIdentifier NULL, resourceUnavailable NULL, ..., securityDenial NULL, qosControlNotSupported NULL, incompleteAddress NULL,

-- changes start here: deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use exceedsCallCapacity NULL, -- destination does not have the capacity for this call aliasesInconsistent NULL, -- multiple aliases in request identify distinct people routeCallToSCN SEQUENCE OF PartyNumber, collectDestination NULL, collectPIN NULL }

I assume we can change both because neither are Decided and these are true irreconcilable errors in the documents, correct? Here are the specifics: We rename the old reasons to "deprecate*", add the new ones after callCapacityExceeded/exceedsCallCapacity, and then in the text of IGv3 and H.225.0v4 say that the old ones shall not be transmitted and if received shall be treated like undefinedReason. Otherwise, a receiver would have to parse the AdmissionReject message differently depending on the version of the transmitter. We, Smith Micro, can actually do that with our ASN.1 parser but I'm guessing that most implementations cannot. Maybe we should even change the type of deprecatedRouteCallToSCN to NULL so that the ASN.1 PER parser would simply skip over the contents via the encapsulating open type. I know that our parser would do this. Would others?

v1 implementations won't have a problem, because they would ignore this reason, anyway, but we could encourage v2 implementations to treat aliasesInconsistent like undefinedReason since they won't know if it is aliasesInconsistent from a v2 EP or some other extended choice from a v3+ EP.

Paul Long Smith Micro Software, Inc.

---

---

Please send E-mail to contact@imtc.org mailto:contact@imtc.org to subscribe or unsubscribe from this list

---

---

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

Paul,

With extension addition fields, I do understand that the encoding is OpenType and the OpenType field's encoding length is included. But my point is that if the field is encoded by the peer EP, how does the ASN.1 decoder know whether to ignore the entire field or decode the OpenType field. If the field is to be ignored, then fine. If the field is not to be ignored, the the types must match between the two entities for a field occupying the same position in the ordering.

What you are proposing can only be achieved if the ASN.1 compiler supports a directive(such as the RELAXPER decoder flag) to inform the encode/decode library to ignore a particular field.

I am not sure if I will support this, though. Personally, H323v3 is in it early stage and let us correct it the right way. We have been in this situation.

- Logan

Paul Long wrote:

Logan,

No, I am proposing this because we are shipping actual v3 endpoints and not stacks (we developed everything in our products--we don't license anything from anybody). Other vendors may, however, be shipping v3 stacks to their licensees. I don't know. Also, H.225.0v2, H.323IGv2, and H.225.0v3 are all Decided Recommendations, therefore they are all "correct" yet contradictory. We now need to find the most interoperable solution to this mess.

Now, on to the particulars...

A v3 GK sends routeCallToSCN to a v3' (v3 + my proposal) EP. The EP attempts to parse this SEQUENCE OF choice as a deprecatedAliasesInconsistent NULL choice (but then treats it semantically like undefinedReason). Obviously the types are different; however, the question is, what will the EP actually do when this happens? Our ASN.1 parser will simply skip over the encoded SEQUENCE OF value and treat it as if a NULL value were encoded. There is no reason for it to check the encoded value since this is a NULL type, after all. It can do this because components not in the extension root are always encapsulated within an open type. (I can explain how this works if necessary.) If the RELAXPER decoder flag is specified with a very popular ASN.1 decoder ;-), the same thing will happen. From my experience, I would guess that most or all licensees of this parser run their decoders this way. Also from my experience, I believe that a very popular H.323 stack and in fact most or all ASN.1 PER decoders behave this way. If anybody knows otherwise (and is not simply guessing), please come forward.

At a higher level, though, remember that we are trying to _minimize_ the overall impact of whatever solution we specify--we cannot eliminate it altogether. On the plus side, notice that if a v2 GK sends aliasesInconsistent to a v3' EP (see attached spreadsheet), there would be absolutely no chance of a decode error, and this is a much more likely scenario these days (many more v2 GKs than v3 GKs). That's why I chose to place deprecatedAliasesInconsistent ahead of deprecatedRouteCallToSCN.

FWIW, here is a summary of the relevant parts of the AdmissionRejectReason type for the different syntaxes under discussion:

Current H.323v2 syntax (with IGv2 applied) aliasesInconsistent NULL -- multiple aliases in request identify distinct people

Current H.323v3 syntax routeCallToSCN SEQUENCE OF PartyNumber, aliasesInconsistent NULL -- multiple aliases in request identify distinct people

Proposed IGv3 syntax deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use callCapacityExceeded NULL, -- destination has exceeded call capacity aliasesInconsistent NULL, -- multiple aliases in request identify distinct people routeCallToSCN SEQUENCE OF PartyNumber

Proposed H.225.0v4 syntax deprecatedAliasesInconsistent NULL, -- do not use deprecatedRouteCallToSCN SEQUENCE OF PartyNumber, -- do not use exceedsCallCapacity NULL, -- destination does not have the capacity for this call aliasesInconsistent NULL, -- multiple aliases in request identify distinct people routeCallToSCN SEQUENCE OF PartyNumber, collectDestination NULL, collectPIN NULL

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Logan Modahala [mailto:lmodahal@CISCO.COM] Sent: Friday, October 06, 2000 9:23 AM To: Paul Long Cc: Mailing list for parties associated with ITU-T Study Group 16; h323implementors@imtc.org; h323implementors@pulver.com Subject: Re: Error in H.323v3 ASN.1

Paul,

If my understanding is as mentioned below, with all due respect, I wish to point out that this proposal will not work.

I assume you are proposing this because the H323v3 code is already sent out by some stack vendors but find it difficult to go to those customers and change thye stack. If I am correct, your proposal is that the H323v3 code that already shipped out will use the "erroneous" v3 spec. i.e the "routeCallToSCN SEQUENCE OF PartyNumber" parameter appearing first; but the new H323v3 code with your proposal has "deprecatedAliasesInconsistent NULL" first. i.e in the logical incresed ordering of the extension additions both take the same position (#3) in the choice. However, one is of type NULL and the other is of type SEQUENCE OF.

Let us say H.323v3 endpoint with erroneous spec use, encodes a message choosing the routeCallToSCN field (poistion #3 with type SEQUENCE OF), the new H.323v3 with your proposed change will attempt to decode that same field to a NULL type. As a result, all the subsequent decodings will be inconsistent based on how many elements were added in the SEQUENCE OF encoding. In this discussion, always remember that the parent type is a CHOICE. Hence there should be one and only one field should be present.

In my opinion, even well known ASN.1 decoders (not appropriate for me to mention names) will go crazy here when a message from H.323v3 EP with erroneous spec use sends a message to the EP using newly proposed spec.

o we have a compatibility problem between the erroneous H.323v3 endpoint and the endpoint using the proposed H.323v3 spec.

• Logan

  ---

             Name: ARJfix.xls
  

  ARJfix.xls Type: Microsoft Excel Worksheet (application/vnd.ms-excel) Encoding: base64

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

Hello all! I would like to bring up this issue once again in order to finally resolve it. Following the prolong discussions on this mailing list and despite our (RADVision's) original view on this issue, we vote for correcting the already published H.323v.3 to include the definitions of the H.323v.2 Implementers Guide. We believe that this direction will lead to the least harmful situation for the currently installed and operating database (and will keep the tradition of H.323 Implementers Guide intact :)) We feel that moving the solution for H.323v.4 (by deprecating both of the current definitions and by introducing a new one) will result in unnecessary overhead for all H.323 versions starting from now.

From RADVison's perspective, we must achieve the final resolution on this

issue immediately in order to be able to provide a fully compliant and interoperable H.323v.3 implementation for all. Best Regards, Orit Levin RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com