From kdbutt at us.ibm.com Mon Oct 2 09:49:27 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Mon, 2 Oct 2006 09:49:27 -0700 Subject: SSC: 05-423: Configurable Early Warning (make host side of buffer centric?) Message-ID: Formatted message: HTML-formatted message All, During the Sept SSC-3 WG when covering 05-423 Configurable Early Warning, I took several suggestions to incorporate. I am working on those, but I need clarification relating to the following suggestion. "Fix to make it host side of buffer centric." It was made related to the text added to the Write command (i.e. all commands it is to be added to). I have looked at the text that is there and I cannot see what is lacking - or what needs to be changed to make it "host side buffer centric". As it is written (see 05-423r2) << If the device server encounters PEW during the processing of a WRITE(16) command, an attempt to finish processing the command shall be made. If all data that is to be written is successfully transferred to the medium, the device server shall establish a unit attention condition with an addi?tional sense code set to END-OF-PARTITION/MEDIUM DETECTED. Encountering PEW should not cause a synchronize operation. >> it seems to cover everything needed. When PEW is encountered a UA (or CC depending on result of ISV survey) is generated. The application client will know that there is only PEWS megabytes of native capacity remaining and it must flush its buffer(s). Please help me understand what is desired differently here. Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com From kdbutt at us.ibm.com Mon Oct 2 10:53:21 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Mon, 2 Oct 2006 10:53:21 -0700 Subject: SSC-3: Configurable Early Warning (Question to ISV's) Message-ID: Formatted message: HTML-formatted message Hello, I am sending this note to the T10 reflector and to a list of ISV contacts to solicit input from ISV's who deal with Tape drives. In response to an earlier query of ISV's, requests were submitted to the SSC-3 Working Group and SMC-3 Working Group to standardize items that would help the tape industry. One of this items was to standardize on a method to allow an application client to program a special early warning notification that would allow the application to ensure it had enough space to clean up prior to reaching EOP. A proposal to meet this request can be found at http://www.t10.org/ftp/t10/document.05/05-423r2.pdf During the September SSC-3 working group meeting I, as author of the proposal, was requested to query the ISV's on the desired notification method. As can be seen in the proposal, it is currently written such that a Unit Attention condition is generated upon entry into this programmed early warning area. Some of those in the working group are concerned that Unit Attentions might not be seen by the applications and wonder if a Check Condition with No Sense (00h) would be a better notification method. If you have a preference, please reply to me at kdbutt at us.ibm.com or at t10 at t10.org prior to November. => UA as exists in the referenced proposal => CC with No Sense (similar to existing EW but only returned once) => Something different (provide description of desired notification) Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com From gop at us.ibm.com Mon Oct 2 12:07:22 2006 From: gop at us.ibm.com (George Penokie) Date: Mon, 2 Oct 2006 14:07:22 -0500 Subject: request byte count in ST_ITS state machine Message-ID: Formatted message: HTML-formatted message Sandeep, The two instances of request byte count in section 9.2.6.2.3.3 are an error. In both cases the value should have been Data-out Buffer Size. I will write a proposal to fix this. Thanks for pointing this out. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 Sandeep taneja Sent by: owner-t10 at t10.org 09/28/2006 09:18 AM To t10 at t10.org cc Monika , George Penokie/Rochester/IBM at IBMUS Subject request byte count in ST_ITS state machine * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Hi all I am referring to sas2r06 version. In Section 9.2.6.2.3.3 ST_ITS2:Initiator_Send_Frame state specs says : "If the confirmation is Transmission Status (Frame Transmitted), and the Transmit Frame request was for a COMMAND frame requesting a write operation, or a write DATA frame where the number of data bytes that have been transmitted is less than the ""request byte count"" and the write data length from the previous XFER_RDY frame, then this state shall wait to receive one of the following confirmations: a) Transmission Status (ACK Received); b) Transmission Status (NAK Received); c) Transmission Status (ACK/NAK Timeout); d) Transmission Status (Connection Lost Without ACK/NAK); or e) XFER_RDY Arrived message." Question : ""Request byte argument"" is used only at Target side.Its not defined for initiator side .then whats its meaning in this context.. Please let me know.... Thanks Regards Sandeep * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From gop at us.ibm.com Mon Oct 2 12:10:05 2006 From: gop at us.ibm.com (George Penokie) Date: Mon, 2 Oct 2006 14:10:05 -0500 Subject: Querry regarding Transport layer (specs sas2r04) Message-ID: Formatted message: HTML-formatted message Sandeep, This is a missed message pass (see below). To fix this Table 147 ? Confirmations sent to the SCSI application layer if a frame transmission or reception table is missing the following rows: Transmission Complete (Command Failed,Connection Failed) Command Complete Received (Service Delivery or Target Failure - Connection Failed) Transmission Complete (Task Failed,Connection Failed) Received Task Management Function - Executed (Service Delivery or Target Failure - Connection Failed) I will write a proposal to fix this. Thanks for pointing this out. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 Sandeep taneja Sent by: owner-t10 at t10.org 09/22/2006 03:11 AM To t10 at t10.org cc Subject Querry regarding Transport layer (specs sas2r04) * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Hi all I have a query regarding the Transmission Complete (Command Failed,Connection Failed) , Transmission Complete (Task Failed,Connection Failed) message. Ques: How ST_IFR will behave upon receiving theses messages from ST_ITS state machine Please let me know..as this is not clearly mentioned in specs Thanks Sandeep * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From keiji_katata at post.pioneer.co.jp Mon Oct 2 18:23:43 2006 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Tue, 3 Oct 2006 10:23:43 +0900 Subject: DVD-R/DL layer jump recording Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hi Joerg, First of all, please refer to Fuji6. Because Fuji7 is under editing. So page number and section number will be changed very often. You and I may be confused. Refer to 4.17.5.1.2 Reserved RZone structure on page 169 of Fuji6r100.pdf. If you reserve a RZone, the R-DL disc has a Layer Jump point already. So you may not need to use Send DVD structure 0x23 with (layer break address -1). Send DVD structure 0x23 is used for Invisible/Incomplete (the last) RZone to set Layer jump address as written in 4.17.5.3 Layer Jump recording on Invisible/Incomplete RZone. The Layer jump address is always end of an ECC block and then is xxxxxFh. R-DL has some unique characteristics as written in 4.17.5.2 RZone reservation. But if the Reservation size is bigger than the Physical Clearance written in Figure 72 - Physical overview of Layers, there is no problem. Do you need two layer jump point? Best regards, Keiji Katata PIONEER CORP. Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)@t10.org on 2006/09/29 18:04:34 $BAw?.(B: DVD-R/DL layer jump recording * From the T10 Reflector (t10 at t10.org), posted by: * Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) * Hi, I am trying to do DVD-R/DL layer jump recording using the simple case of one single hand crafted layer break. After reading Mtfuji7 and MMC5, I believe that this is done via: Send mode page 5 with write mode == 4 Send reserve rzone with total data size Send DVD structure 0x23 with (layer break address -1) I am trying this with a Plextor PXW 755 and Firmware 1.01 that does not accept the Send DVD structure 0x23 wth any variant of the layer break address. Could someone help me and tell me what I am doing wrong please? Thank you in advance J?g -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?g Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From gop at us.ibm.com Tue Oct 3 06:23:55 2006 From: gop at us.ibm.com (George Penokie) Date: Tue, 3 Oct 2006 08:23:55 -0500 Subject: connection info in target transport layer(ST_TFR) Message-ID: Formatted message: HTML-formatted message Sandeep, You are correct. I will change port layer to SCSI application layer in the proposal. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 Sandeep taneja 10/03/2006 05:50 AM To t10 at t10.org cc George Penokie/Rochester/IBM at IBMUS, Monika Subject connection info in target transport layer(ST_TFR) Hi all Specs sas2r06 says that Transport layer may check the hashed source & destination address in the recieved frame based on the "connection information" Taken from specs sas2r06 page:422 --------------------------------------------------------------- If the frame type is correct relative to the Frame Received confirmation, then this state machine may check that the hashed source SAS address matches the SAS address of the SAS port that transmitted the frame and that the hashed destination SAS address matches the SAS address of the SAS port that received the frame based on the "connection information." ----------------------------------------------------------------- Ques:- How Target side checks the received address for the first recieved frame(eg recieved Command frame Source & destination address). if Connection info is maintained by the recieved Open address frame. then how these are communicated to transport layer Please help... Thanks & regards Sandeep From sandeep.taneja at nsysinc.com Tue Oct 3 06:30:50 2006 From: sandeep.taneja at nsysinc.com (Sandeep taneja) Date: Tue, 3 Oct 2006 07:30:50 -0600 Subject: Querry regarding Transport layer (specs sas2r04) Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Sir Thanks for ur kind response. there is another point that i would like to bring in ur kind notice On Page 423 sas2r06 states If the frame type is TASK, this state machine checks tags, the RETRANSMIT bit in the new TASK frame is set to one, and the tag for the new TASK frame is the same as the tag for a previous TASK frame where the task management function for the previous TASK frame is not complete, then this state machine shall discard the new TASK frame and not send a Task Management Request Received confirmation to the "port layer". point := Instead of port layer it should be application layer as the Task Management Request Received confirmation sent only to application layer. Thanks once again Regards Sandeep On Tue, 2006-10-03 at 00:40, George Penokie wrote: > Sandeep, > > This is a missed message pass (see below). To fix this Table 147 ? > Confirmations sent to the SCSI application layer if a frame transmission > or reception table is missing the following rows: > > Transmission Complete (Command Failed,Connection Failed) Command > Complete Received (Service Delivery or Target > Failure - > Connection Failed) > Transmission Complete (Task Failed,Connection Failed) Received Task > Management Function - Executed (Service > Delivery or > Target Failure - Connection Failed) > > I will write a proposal to fix this. > > Thanks for pointing this out. > > Bye for now, > George Penokie > > Dept 9A8 030-3 A410 > E-Mail: gop at us.ibm.com > Internal: 553-5208 > External: 507-253-5208 > > > > Sandeep taneja > Sent by: owner-t10 at t10.org > 09/22/2006 03:11 AM > > To > t10 at t10.org > cc > > Subject > Querry regarding Transport layer (specs sas2r04) > > > > > > > * From the T10 Reflector (t10 at t10.org), posted by: > * Sandeep taneja > * > Hi all > > I have a query regarding the Transmission Complete (Command > Failed,Connection Failed) , Transmission Complete (Task > Failed,Connection Failed) message. > > > Ques: How ST_IFR will behave upon receiving theses messages from ST_ITS > state machine > > Please let me know..as this is not clearly mentioned in specs > Thanks > Sandeep > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From sandeep.taneja at nsysinc.com Tue Oct 3 06:30:55 2006 From: sandeep.taneja at nsysinc.com (Sandeep taneja) Date: Tue, 3 Oct 2006 07:30:55 -0600 Subject: connection info in target transport layer(ST_TFR) Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Hi all Specs sas2r06 says that Transport layer may check the hashed source & destination address in the recieved frame based on the "connection information" Taken from specs sas2r06 page:422 --------------------------------------------------------------- If the frame type is correct relative to the Frame Received confirmation, then this state machine may check that the hashed source SAS address matches the SAS address of the SAS port that transmitted the frame and that the hashed destination SAS address matches the SAS address of the SAS port that received the frame based on the "connection information." ----------------------------------------------------------------- Ques:- How Target side checks the received address for the first recieved frame(eg recieved Command frame Source & destination address). if Connection info is maintained by the recieved Open address frame. then how these are communicated to transport layer Please help... Thanks & regards Sandeep * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From gop at us.ibm.com Tue Oct 3 13:10:20 2006 From: gop at us.ibm.com (George Penokie) Date: Tue, 3 Oct 2006 15:10:20 -0500 Subject: connection info in target transport layer(ST_TFR) Message-ID: Formatted message: HTML-formatted message Sandeep, The source address that a frame is checked against is the SAS source address received in the open address frame. The current SAS-2 does not pass that information from the link layer to the port layer. I will request a change that will add a SAS source address argument to the connection opened confirmation. The SAS source address is already passed between the port and transport layer as part of the frame received confirmation. As defined in section 9.2.6.1 ST state machines overview. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 Sandeep taneja Sent by: owner-t10 at t10.org 10/03/2006 08:30 AM To t10 at t10.org cc George Penokie/Rochester/IBM at IBMUS, Monika Subject connection info in target transport layer(ST_TFR) * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Hi all Specs sas2r06 says that Transport layer may check the hashed source & destination address in the recieved frame based on the "connection information" Taken from specs sas2r06 page:422 --------------------------------------------------------------- If the frame type is correct relative to the Frame Received confirmation, then this state machine may check that the hashed source SAS address matches the SAS address of the SAS port that transmitted the frame and that the hashed destination SAS address matches the SAS address of the SAS port that received the frame based on the "connection information." ----------------------------------------------------------------- Ques:- How Target side checks the received address for the first recieved frame(eg recieved Command frame Source & destination address). if Connection info is maintained by the recieved Open address frame. then how these are communicated to transport layer Please help... Thanks & regards Sandeep * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From zdaggett at hcm.hitachi.com Wed Oct 4 05:41:20 2006 From: zdaggett at hcm.hitachi.com (Daggett, Zane) Date: Wed, 4 Oct 2006 08:41:20 -0400 Subject: Contact Message-ID: Formatted message: HTML-formatted message Anyone have current contact info for Greg McSorely? Zane Daggett Vice President Electronics Group Hitachi Cable Manchester, Inc. 800-772-0116 x 236 ************************************************************************ ************************** CONFIDENTIALITY NOTICE: If you have received this e-mail in error, please immediately notify the sender by e-mail at the address shown. This e-mail transmission and any attachment (s) may contain confidential information. The information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2005 Hitachi Cable Manchester, Inc. ************************************************************************ ************************** From zdaggett at hcm.hitachi.com Wed Oct 4 08:00:24 2006 From: zdaggett at hcm.hitachi.com (Daggett, Zane) Date: Wed, 4 Oct 2006 11:00:24 -0400 Subject: Contact Message-ID: Formatted message: HTML-formatted message Thank you all. I have reached him. Zane Zane Daggett Vice President Electronics Group Hitachi Cable Manchester, Inc. 800-772-0116 x 236 ************************************************************************ ************************** CONFIDENTIALITY NOTICE: If you have received this e-mail in error, please immediately notify the sender by e-mail at the address shown. This e-mail transmission and any attachment (s) may contain confidential information. The information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2005 Hitachi Cable Manchester, Inc. ************************************************************************ ************************** From Daniel.Colegrove at hitachigst.com Thu Oct 5 11:13:20 2006 From: Daniel.Colegrove at hitachigst.com (Daniel.Colegrove at hitachigst.com) Date: Thu, 5 Oct 2006 11:13:20 -0700 Subject: One last November Meeting Hotel Booking Reminder Message-ID: Formatted message: HTML-formatted message Dear T10 Reflector List Member: Please remember to book your November T10 hotel reservation. The cut off date is Tomorrow (October 6). Meeting announcement: http://www.t10.org/ftp/t10/announce/ann-m076.pdf Best Regards, Daniel J. Colegrove Hitachi Global Storage Technologies daniel.colegrove at hitachigst.com From lohmeyer at t10.org Thu Oct 5 12:00:02 2006 From: lohmeyer at t10.org (John Lohmeyer) Date: Thu, 05 Oct 2006 13:00:02 -0600 Subject: Fwd: INCITS/T10 International Representative - Call for Volunteers Closes November 6, 2006 Message-ID: Formatted message: HTML-formatted message All, If you are interested in applying for the position of T10 International Representative, please read the below memo. Jennifer, Gary, and I will be glad to answer any questions. John >Subject: INCITS/T10 International Representative - Call for Volunteers Closes > November 6, 2006 >Date: Thu, 5 Oct 2006 14:04:10 -0400 >From: "Garner, Jennifer" >To: "Lohmeyer, John" >Cc: "Robinson, Gary" , > "Purnell, Parthenia" > , > "Barra, Lynn" > >John > >As you may recall, Gary Robinsons current term as T10 International Representative will expire in March 2007. Please distribute the attached call for volunteers to serve as INCITS/T10 IR to the members of the committee at your earliest opportunity. > >I will be in touch after the call has closed on November 6. > >Best regards - > > > >Jennifer T. Garner >Associate Director, Standards Programs >INCITS/Information Technology Industry Council >1250 Eye Street, NW - Suite 200 >Washington, DC 20005 >202.626.5737 >e-mail: jgarner at itic.org >website: http://www.incits.org>www.incits.org > > > > ============================================================= > > > >in061167 > >INCITS >InterNational Committee for Information Technology Standards >INCITS Secretariat, Information Technology Industry Council (ITI) >1250 Eye St. NW, Suite 200, Washington, DC 20005 >Telephone 202-737-8888; Fax 202-638-4922 > >Date: October 5, 2006 >Date Due: November 6, 2006 >Reply to: Jennifer T. Garner >Phone: (202) 626-5737 >email: jgarner at itic.org >cc: John Lohmeyer, INCITS/T10 Chairman > Gary Robinson, INCITS/T10 IR > >---------- >To: The Members of INCITS/T10 > >From: Jennifer T. Garner, for the INCITS Secretariat > >Subject: CALL FOR VOLUNTEERS - International Representative - INCITS/T10, SCSI Storage Interfaces > >---------- > >The term of office of the current INCITS/T10 International Representative, Mr. Gary Robinson, will expire in March 2007. This first call for volunteers to serve as International Representative of INCITS/T10 is being issued to the members of T10 and will close on November 6, 2006. > >Any member of the INCITS Subgroup is welcome to volunteer to serve. Before one considers doing so, however, the commitment in time and responsibilities should be considered. Officers must actively support the administrative structure that ensures due process to all participants, assists in reaching consensus and protects the accreditation of the entire system. [There is no limit to the number of terms an individual may serve. There is a rule prohibiting one individual from being appointed to two or more offices of the same committee simultaneously.] > >The http://www.incits.org/rd2/main.htm>INCITS/RD-2, Organization and Procedures of INCITS, generally describes officers' responsibilities, and a more detailed list of duties has been compiled in the http://www.incits.org/rd3/rd3.htm>INCITS/RD-3, Officers' Guide. > >Those willing to make this commitment must submit three written statements in support of their candidacy: > * A one-page statement of experience, indicating the volunteer's expertise in the subgroup's program of work, voluntary standards efforts, committee experience and leadership abilities (to be forwarded to the INCITS Subgroup for an advisory ballot if there is more than one candidate). > > > * A statement of management support for a three-year term on company letterhead acknowledging the additional workload, financial resources and duties required of an officer over and above that of a technical participant. This statement must be signed by the candidate's management and submitted on their organization's letterhead. > >The statement of management support for the three-year term is a good faith commitment, not a legal binding commitment. If future circumstances require the applicant to resign from the office before the term has been fulfilled, this will be accepted without prejudice. > * A statement as to whether or not the candidate is a representative of a U.S. domiciled organization. > >Any supplemental materials will be forwarded along with the advisory ballot to INCITS, which appoints all INCITS Subgroup officers. The statements from candidates wishing to serve in the above referenced position on the INCITS Subgroup should be sent to the attention of Jennifer Garner (jgarner at itic.org) no later than November 6, 2006. > > > > -- John Lohmeyer Email: lohmeyer at t10.org LSI Logic Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 From g.robinson at gsrobin.com Thu Oct 5 12:03:19 2006 From: g.robinson at gsrobin.com (GSRobinson) Date: Thu, 05 Oct 2006 15:03:19 -0400 Subject: Fwd: INCITS/T10 International Representative - Call for Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * GSRobinson * I am willing to serve as T10 IR for another term At 10/5/2006 01:00 PM, John Lohmeyer wrote: >All, > >If you are interested in applying for the position of T10 International >Representative, please read the below memo. Jennifer, Gary, and I will be >glad to answer any questions. > >John > > >>Subject: INCITS/T10 International Representative - Call for Volunteers >>Closes >> November 6, 2006 >>Date: Thu, 5 Oct 2006 14:04:10 -0400 >>From: "Garner, Jennifer" >>To: "Lohmeyer, John" >>Cc: "Robinson, Gary" , >> "Purnell, Parthenia" >> , >> "Barra, Lynn" >> >>John >> >>As you may recall, Gary Robinsons current term as T10 International >>Representative will expire in March 2007. Please distribute the attached >>call for volunteers to serve as INCITS/T10 IR to the members of the >>committee at your earliest opportunity. >> >>I will be in touch after the call has closed on November 6. >> >>Best regards - >> >> >> >>Jennifer T. Garner >>Associate Director, Standards Programs >>INCITS/Information Technology Industry Council >>1250 Eye Street, NW - Suite 200 >>Washington, DC 20005 >>202.626.5737 >>e-mail: jgarner at itic.org >>website: http://www.incits.org>www.incits.org >> >> >> >> ============================================================= >> >> >> >>in061167 >> >>INCITS >>InterNational Committee for Information Technology Standards >>INCITS Secretariat, Information Technology Industry Council (ITI) >>1250 Eye St. NW, Suite 200, Washington, DC 20005 >>Telephone 202-737-8888; Fax 202-638-4922 >> >>Date: October 5, 2006 >>Date Due: November 6, 2006 >>Reply to: Jennifer T. Garner >>Phone: (202) 626-5737 >>email: jgarner at itic.org >>cc: John Lohmeyer, INCITS/T10 Chairman >> Gary Robinson, INCITS/T10 IR >> >>---------- >>To: The Members of INCITS/T10 >> >>From: Jennifer T. Garner, for the INCITS Secretariat >> >>Subject: CALL FOR VOLUNTEERS - International Representative - INCITS/T10, >>SCSI Storage Interfaces >> >>---------- >> >>The term of office of the current INCITS/T10 International >>Representative, Mr. Gary Robinson, will expire in March 2007. This first >>call for volunteers to serve as International Representative of >>INCITS/T10 is being issued to the members of T10 and will close on >>November 6, 2006. >> >>Any member of the INCITS Subgroup is welcome to volunteer to serve. >>Before one considers doing so, however, the commitment in time and >>responsibilities should be considered. Officers must actively support the >>administrative structure that ensures due process to all participants, >>assists in reaching consensus and protects the accreditation of the >>entire system. [There is no limit to the number of terms an individual >>may serve. There is a rule prohibiting one individual from being >>appointed to two or more offices of the same committee simultaneously.] >> >>The http://www.incits.org/rd2/main.htm>INCITS/RD-2, Organization and >>Procedures of INCITS, generally describes officers' responsibilities, and >>a more detailed list of duties has been compiled in the >>http://www.incits.org/rd3/rd3.htm>INCITS/RD-3, Officers' Guide. >> >>Those willing to make this commitment must submit three written >>statements in support of their candidacy: >> * A one-page statement of experience, indicating the volunteer's >> expertise in the subgroup's program of work, voluntary standards >> efforts, committee experience and leadership abilities (to be forwarded >> to the INCITS Subgroup for an advisory ballot if there is more than one >> candidate). >> >> >> * A statement of management support for a three-year term on company >> letterhead acknowledging the additional workload, financial resources >> and duties required of an officer over and above that of a technical >> participant. This statement must be signed by the candidate's >> management and submitted on their organization's letterhead. >> >>The statement of management support for the three-year term is a good >>faith commitment, not a legal binding commitment. If future circumstances >>require the applicant to resign from the office before the term has been >>fulfilled, this will be accepted without prejudice. >> * A statement as to whether or not the candidate is a representative >> of a U.S. domiciled organization. >> >>Any supplemental materials will be forwarded along with the advisory >>ballot to INCITS, which appoints all INCITS Subgroup officers. The >>statements from candidates wishing to serve in the above referenced >>position on the INCITS Subgroup should be sent to the attention of >>Jennifer Garner (jgarner at itic.org) no later than November 6, 2006. >> >> >> >> > >-- >John Lohmeyer Email: lohmeyer at t10.org >LSI Logic Corp. Voice: +1-719-533-7560 >4420 ArrowsWest Dr. Cell: +1-719-338-1642 >Colo Spgs, CO 80907 Gary S. Robinson g.robinson at gsrobin.com * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From keiji_katata at post.pioneer.co.jp Fri Oct 6 02:03:23 2006 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Fri, 6 Oct 2006 18:03:23 +0900 Subject: revised RW-DL proposal Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I put revised RW-DL proposal based on the action items of Sep. Fuji meeting in ftp.avc-pioneer.com/Mtfuji_7/Proposal/Oct06/pioneer.zip. READ_DISC_STRUCTURE.pdf has a change from Minutes that I add "Number of unrecorded blocks in data area for minimum capacity" field to Formatted Area Information (Format Code = 25h). Because my original idea had this information in Formattable Capacity Descriptor 18h. I move this in to Formatted Area Information. See you at JVC. Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From keiji_katata at post.pioneer.co.jp Fri Oct 6 02:35:48 2006 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Fri, 6 Oct 2006 18:35:48 +0900 Subject: October Agenda proposal Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I put an agenda proposal in ftp.avc-pioneer.com/Mtfuji_7/Proposal/Oct06/Agenda Oct06.doc. Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Daniel.Colegrove at hitachigst.com Fri Oct 6 13:21:37 2006 From: Daniel.Colegrove at hitachigst.com (Daniel.Colegrove at hitachigst.com) Date: Fri, 6 Oct 2006 13:21:37 -0700 Subject: November meeting room block sold out on some days Message-ID: Formatted message: HTML-formatted message Dear T10 Reflector Member: I want to let you know that the meeting room block at the Atrium Suites has sold out on some of the days. I had to estimate how many guest rooms we could guarantee and I went a little under. There are still rooms available but not at the group rate. The rate will vary from now until all the rooms in the hotel are sold out. I will still get credit for your stay to defray catering and meeting room costs even if you book after today. Thanks to everyone for booking. http://www.t10.org/ftp/t10/announce/ann-m076.pdf Best Regards, Daniel J. Colegrove Hitachi Global Storage Technologies daniel.colegrove at hitachigst.com From roweber at IEEE.org Sat Oct 7 18:49:55 2006 From: roweber at IEEE.org (Ralph Weber) Date: Sat, 07 Oct 2006 20:49:55 -0500 Subject: SPC-4 r07a URL Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Ralph Weber * There is a typo in the previous message (surprise!). The URL for SPC-4 r07a is: http://www.t10.org/ftp/t10/drafts/spc4/spc4r07a.pdf Sorry, .Ralph * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From roweber at IEEE.org Sat Oct 7 18:48:14 2006 From: roweber at IEEE.org (Ralph Weber) Date: Sat, 07 Oct 2006 20:48:14 -0500 Subject: SPC-4 r07 (and r07a) available Message-ID: Formatted message: HTML-formatted message The SPC-4 revision containing the changes approved in September has been uploaded as SPC-4 r07: http://www.t10.org/ftp/t10/drafts/spc4/spc4r07.pdf For the more adventurous, there is SPC-4 r07a: http://www.t10.org/ftp/t10/drafts/spc4/spc4r07.pdf SPC-4 r07a has all the technical content found in r07, plus one invisible and two slightly visible changes. * The sources for SPC-4 r07a are in FrameMaker 7.2, not the tried-and-true FrameMaker 6.0 which has been used for several years worth of SPC-3 and SPC-4 revisions. * All device-type vs code value tables (e.g, the ASC/ASCQ lists) have been converted from a column-per-device-type format to a tab-separated format. This change reduced the source file sizes substantially, cut minutes off the time required to build the PDF, and eliminate a bazillion error messages from the PDF Distiller. In addition, the DTL... letters were squished together more than was previously possible and the description column grew by a few tenths of an inch which allowed for fewer line wraps. The total PDF size shrunk by one page as a result. * A handful of typos were fixed (e.g., the Description column in the Diagnostic pages table was headed with 'Mode Page name'). Devotees of how SPC-4 looks will surely want to grab a copy of r07a. The less finicky may prefer r07. Enjoy, .Ralph From lohmeyer at t10.org Sat Oct 7 23:02:23 2006 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 8 Oct 2006 00:02:23 -0600 Subject: Recent T10 documents uploaded since 2006/10/01 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SSC: Configurable EW (by: Kevin Butt) T10/05-423r2 Uploaded: 2006/10/02 31497 bytes ftp://ftp.t10.org/t10/document.05/05-423r2.pdf ADC-2 Add Encrypting field in VHF data (by: Noud Snelder) T10/06-226r1 Uploaded: 2006/10/05 17619 bytes ftp://ftp.t10.org/t10/document.06/06-226r1.pdf SAS-2 Modifications to the SAS Speed Negotiation (by: Amr Wassak, Stephen Finch) T10/06-324r4 Uploaded: 2006/10/01 316057 bytes ftp://ftp.t10.org/t10/document.06/06-324r4.pdf SMC-3: Element Statistics log page for SMC (by: Kevin Marks) T10/06-394r1 Uploaded: 2006/10/02 28817 bytes ftp://ftp.t10.org/t10/document.06/06-394r1.pdf SMC-3: Diagnostics Data log page (by: Kevin Marks) T10/06-395r1 Uploaded: 2006/10/02 41824 bytes ftp://ftp.t10.org/t10/document.06/06-395r1.pdf SMC-3 Medium type codes (by: Noud Snelder) T10/06-452r0 Uploaded: 2006/10/05 17305 bytes ftp://ftp.t10.org/t10/document.06/06-452r0.pdf SSC-3 Add a random number page to the Tape Data Encryption protocol (by: Paul Entzel) T10/06-453r0 Uploaded: 2006/10/06 21582 bytes ftp://ftp.t10.org/t10/document.06/06-453r0.pdf Clarifying Identifying Information Types Requirements (by: Ralph O. Weber) T10/06-454r0 Uploaded: 2006/10/06 27465 bytes ftp://ftp.t10.org/t10/document.06/06-454r0.pdf Lost SET IDENTIFYING INFORMATION Parameter List Length requirement (by: Ralph O. Weber) T10/06-455r0 Uploaded: 2006/10/06 20002 bytes ftp://ftp.t10.org/t10/document.06/06-455r0.pdf Working Drafts -------------- SCSI Primary Commands - 4 (SPC-4) (Editor: Ralph Weber) Rev: 07 Uploaded: 2006/10/06 3990577 bytes ftp://ftp.t10.org/t10/drafts/spc4/spc4r07.pdf SCSI Primary Commands - 4 (SPC-4) (Editor: Ralph Weber) Rev: 07a Uploaded: 2006/10/07 3986560 bytes ftp://ftp.t10.org/t10/drafts/spc4/spc4r07a.pdf (Report generated on 2006/10/08 at 00:02:22) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From David.Peterson at mcdata.com Sun Oct 8 12:34:04 2006 From: David.Peterson at mcdata.com (David Peterson) Date: Sun, 8 Oct 2006 13:34:04 -0600 Subject: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From David.Peterson at mcdata.com Sun Oct 8 12:34:04 2006 From: David.Peterson at mcdata.com (David Peterson) Date: Sun, 8 Oct 2006 13:34:04 -0600 Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From dougg at torque.net Sun Oct 8 19:14:16 2006 From: dougg at torque.net (Douglas Gilbert) Date: Sun, 08 Oct 2006 22:14:16 -0400 Subject: sat-r09: invalid command operation code Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Douglas Gilbert * Section 4 of sat-r09 contains this paragraph: "If the SATL receives a SCSI request specifying any value in any field of the CDB that the SATL does not support, unless oterwise (sic) specified in the description of command, the SATL shall terminate the command with CHECK CONDITION status and with the sense key set to ILLEGAL REQUEST and the additional sense code set to ILLEGAL FIELD IN CBD (see SPC-3)." Section 4.3.1 of SPC-3 (or SPC-4 rev07a or SPC-2) seemingly contradicts the above if the opcode itself (i.e first byte of the CDB) is not supported. In that case the additional sense code should be INVALID COMMAND OPERATION CODE. Douglas Gilbert * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Peter at Smart-Projects.net Mon Oct 9 06:59:17 2006 From: Peter at Smart-Projects.net (Peter Van Hove) Date: Mon, 9 Oct 2006 15:59:17 +0200 Subject: HD DVD-RAM vs HD DVD-RW Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * Hi, I'm confused. Will there be two different rewriteable HD DVD formats ? -RW and -RAM ? Or has it been decided that there will be only one of the two ? The reason for asking is that I couldn't find a profile for HD DVD-RW in the latest specs. There is one for DVD-RAM. Your insight appreciated ! Peter * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From sandeep.taneja at nsysinc.com Mon Oct 9 09:53:03 2006 From: sandeep.taneja at nsysinc.com (Sandeep taneja) Date: Mon, 9 Oct 2006 10:53:03 -0600 Subject: Hash address Generation Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Hi all I have a little doubt regarding the Hash Address generation Logic Ques: The following two 64 bit address maps to same 24 bit address 64 bit address value 23 bit hash adress 00000000_00000001h DB2777h FFFFFFFF_FFFFFFFFh DB2777h Then How Hash address is used to check that whether frame is routed properly or not , as from this we can assume that Hash Generation Logic is not One to One (64 bit address maps to unique 24 bit hash address value). Plz suggest......... regards Sandeep * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Elliott at hp.com Mon Oct 9 11:04:35 2006 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Mon, 9 Oct 2006 13:04:35 -0500 Subject: Hash address Generation Message-ID: Attachment #1: smime.p7s The hashed addresses just allow a second level check and are not crucial to any operation. > -----Original Message----- > From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf > Of Sandeep taneja > Sent: Monday, October 09, 2006 11:53 AM > To: t10 at t10.org > Cc: Monika > Subject: Hash address Generation > > * From the T10 Reflector (t10 at t10.org), posted by: > * Sandeep taneja > * > Hi all > > I have a little doubt regarding the Hash Address generation Logic > > Ques: The following two 64 bit address maps to same 24 bit address > > 64 bit address value 23 bit hash adress > 00000000_00000001h DB2777h > FFFFFFFF_FFFFFFFFh DB2777h > > Then How Hash address is used to check that whether frame is routed > properly or not , as from this we can assume that Hash > Generation Logic > is not One to One (64 bit address maps to unique 24 bit hash address > value). > > > Plz suggest......... > > regards > Sandeep > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > From gop at us.ibm.com Mon Oct 9 11:19:02 2006 From: gop at us.ibm.com (George Penokie) Date: Mon, 9 Oct 2006 13:19:02 -0500 Subject: Hash address Generation Message-ID: Formatted message: HTML-formatted message Sandeep, We know that the hash addresses will duplicate. It is not possible for every 64 SAS address value to be uniquely identified in a 23 bit value. It's a question of probabilities. So given that the SAS addresses have to follow a certain structure to be valid there is a very low probability that two SAS addresses in the same system will hash to the same value and, even if that did happen, that a frame between those two would get misdirected. By the way your example cannot happen with a valid SAS address. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 Sandeep taneja Sent by: owner-t10 at t10.org 10/09/2006 11:53 AM To t10 at t10.org cc Monika Subject Hash address Generation * From the T10 Reflector (t10 at t10.org), posted by: * Sandeep taneja * Hi all I have a little doubt regarding the Hash Address generation Logic Ques: The following two 64 bit address maps to same 24 bit address 64 bit address value 23 bit hash adress 00000000_00000001h DB2777h FFFFFFFF_FFFFFFFFh DB2777h Then How Hash address is used to check that whether frame is routed properly or not , as from this we can assume that Hash Generation Logic is not One to One (64 bit address maps to unique 24 bit hash address value). Plz suggest......... regards Sandeep * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From paulw at marvell.com Mon Oct 9 17:39:15 2006 From: paulw at marvell.com (Paul Wassenberg) Date: Mon, 9 Oct 2006 17:39:15 -0700 Subject: [T11.3] RE: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Hi Dave, Could you clarify the difference between options A & B? Regards, Paul Wassenberg Marvell Semiconductor ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From paulw at marvell.com Mon Oct 9 17:39:15 2006 From: paulw at marvell.com (Paul Wassenberg) Date: Mon, 9 Oct 2006 17:39:15 -0700 Subject: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Hi Dave, Could you clarify the difference between options A & B? Regards, Paul Wassenberg Marvell Semiconductor ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From daviburg at windows.microsoft.com Mon Oct 9 16:54:34 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Mon, 9 Oct 2006 16:54:34 -0700 Subject: HD DVD-RAM vs HD DVD-RW Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Hi Peter, Two different rewritable formats for HD DVD have or are being define, similar to what happened for standard definition DVD 'dash'. Although HD DVD-RAM specification is completed and its command set integrated into MMC5, I am not aware of any market available recorder. HD DVD-RW is currently been finalized and there is an on-going discussion for the command set at Mt Fuji meetings. Your expert opinion will likely be helpful to the committee if you can join the discussions. Best regards, David Burg, Microsoft Corporation. -----Original Message----- From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Peter Van Hove Sent: Monday, October 09, 2006 6:59 AM To: t10 at t10.org Subject: HD DVD-RAM vs HD DVD-RW * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * Hi, I'm confused. Will there be two different rewriteable HD DVD formats ? -RW and -RAM ? Or has it been decided that there will be only one of the two ? The reason for asking is that I couldn't find a profile for HD DVD-RW in the latest specs. There is one for DVD-RAM. Your insight appreciated ! Peter * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From michael.banther at hp.com Tue Oct 10 02:20:59 2006 From: michael.banther at hp.com (Banther, Michael) Date: Tue, 10 Oct 2006 10:20:59 +0100 Subject: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Attachment #1: banther_michael.vcf Hi Dave, HP is working with a vendor to determine if they can support CISC in a way that we can use. It's an active discussion. However, until we achieve some clarity with them, HP cannot state a preference. I'm hoping to have something solid by the November FCP-4 meeting. Regards, Michael Banther Hewlett-Packard Ltd. +44 117 312 9503 ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: 08 October 2006 20:34 To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From Peter at Smart-Projects.net Tue Oct 10 08:29:50 2006 From: Peter at Smart-Projects.net (Peter Van Hove) Date: Tue, 10 Oct 2006 17:29:50 +0200 Subject: BD Dual Layer Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * How does one see how many layers a BD disc has ? BD-ROM, BD-R and BD-RE (blank and written) There are no specific features for it anymore, as was the case for DVD+R and DVD+RW And I can't find it via Read Disc Structure either ? I'm sure it's there somewhere ? :) I just keep looking over it probably ? . * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From kdbutt at us.ibm.com Tue Oct 10 11:46:36 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Tue, 10 Oct 2006 11:46:36 -0700 Subject: [T11.3] RE: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Paul, option A is a requirement. option B is a strong suggestion, but not requirement. Vendors should move to being able to do this. This is the weasel wording to allow existing implementations that cannot comply with the desire to comply with the standard. Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com http://www-03.ibm.com/servers/storage/ "Paul Wassenberg" Sent by: owner-t10 at t10.org 10/09/2006 05:39 PM To "David Peterson" , cc Subject RE: FCP-4: Continuously Increasing SEQ_CNT Hi Dave, Could you clarify the difference between options A & B? Regards, Paul Wassenberg Marvell Semiconductor From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From David.Peterson at mcdata.com Tue Oct 10 12:14:11 2006 From: David.Peterson at mcdata.com (David Peterson) Date: Tue, 10 Oct 2006 13:14:11 -0600 Subject: [T11.3] RE: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Howdy Paul, Option a requires that CISC be implemented and used for Class 3 service. Option b strongly suggests that CISC be implemented and used for Class 3 service (i.e., it is not required). ...Dave (no disclaimer) ________________________________ From: Paul Wassenberg [mailto:paulw at marvell.com] Sent: Monday, October 09, 2006 7:39 PM To: David Peterson; t10 at t10.org Cc: t11_3 at t11.org Subject: RE: FCP-4: Continuously Increasing SEQ_CNT Hi Dave, Could you clarify the difference between options A & B? Regards, Paul Wassenberg Marvell Semiconductor ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From kdbutt at us.ibm.com Tue Oct 10 11:46:36 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Tue, 10 Oct 2006 11:46:36 -0700 Subject: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Paul, option A is a requirement. option B is a strong suggestion, but not requirement. Vendors should move to being able to do this. This is the weasel wording to allow existing implementations that cannot comply with the desire to comply with the standard. Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com http://www-03.ibm.com/servers/storage/ "Paul Wassenberg" Sent by: owner-t10 at t10.org 10/09/2006 05:39 PM To "David Peterson" , cc Subject RE: FCP-4: Continuously Increasing SEQ_CNT Hi Dave, Could you clarify the difference between options A & B? Regards, Paul Wassenberg Marvell Semiconductor From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From David.Peterson at mcdata.com Tue Oct 10 12:14:11 2006 From: David.Peterson at mcdata.com (David Peterson) Date: Tue, 10 Oct 2006 13:14:11 -0600 Subject: FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Howdy Paul, Option a requires that CISC be implemented and used for Class 3 service. Option b strongly suggests that CISC be implemented and used for Class 3 service (i.e., it is not required). ...Dave (no disclaimer) ________________________________ From: Paul Wassenberg [mailto:paulw at marvell.com] Sent: Monday, October 09, 2006 7:39 PM To: David Peterson; t10 at t10.org Cc: t11_3 at t11.org Subject: RE: FCP-4: Continuously Increasing SEQ_CNT Hi Dave, Could you clarify the difference between options A & B? Regards, Paul Wassenberg Marvell Semiconductor ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From daviburg at windows.microsoft.com Tue Oct 10 12:16:48 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Tue, 10 Oct 2006 12:16:48 -0700 Subject: BD Dual Layer Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Hi Peter, I think you are looking for the Read Disc Structure, Media Type 0001b (BD) for Format Code 00h aka Disc Information (DI). BD uses a system of class and version to identify the discs. Unfortunately the details of the class/version and the DI definitions are kept within the Blu-ray Disc Founders' physical specifications. Is there a BD representative here that can provide a public specification reference to help Peter? Is there an ECMA or ISO specification effort for BD? Best regards, David Burg. -----Original Message----- From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Peter Van Hove Sent: Tuesday, October 10, 2006 8:30 AM To: t10 at t10.org Cc: mtfuji5 at avc-pioneer.com Subject: BD Dual Layer * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * How does one see how many layers a BD disc has ? BD-ROM, BD-R and BD-RE (blank and written) There are no specific features for it anymore, as was the case for DVD+R and DVD+RW And I can't find it via Read Disc Structure either ? I'm sure it's there somewhere ? :) I just keep looking over it probably ? . * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Peter at Smart-Projects.net Tue Oct 10 13:34:56 2006 From: Peter at Smart-Projects.net (Peter Van Hove) Date: Tue, 10 Oct 2006 22:34:56 +0200 Subject: BD Dual Layer Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * Dear David, Thank you for getting back to me on this. >> I think you are looking for the Read Disc Structure, Media Type 0001b (BD) for Format Code 00h aka Disc Information (DI). Right ... the PIC isn't it ? I don't see the layer information in there. Or is it: "Number of DI units in each DI block/ Number of the Layers to which this DI unit applies" But I'm not sure how to interpret that ? >> BD uses a system of class and version to identify the discs. I see, like what is returned in the two BD (read and write) "features". But in that case they are the drive's capabilities, not the disc characteristscs. Indeed, I have wondered about that because it would also let me identify if the drive is a Dual Layer capable writer or not. I can't help but feel that such information: - amount of layers on the disc, - drive capability to write DL or not, - mounted disc is DL or not should be easily available to a host (software application) ? And that MMC (Mnt Fuji) should make that information available ? Group, thanks for any information that can be shared ! I mean hey, if IsoBuster mounts your discs right using your hardware, then you have an excellent tool as a developer :) Peter ------------------------------------------------------- ----- Original Message ----- From: "David Burg" To: "Peter Van Hove" ; Cc: Sent: Tuesday, October 10, 2006 9:16 PM Subject: RE: BD Dual Layer Hi Peter, I think you are looking for the Read Disc Structure, Media Type 0001b (BD) for Format Code 00h aka Disc Information (DI). BD uses a system of class and version to identify the discs. Unfortunately the details of the class/version and the DI definitions are kept within the Blu-ray Disc Founders' physical specifications. Is there a BD representative here that can provide a public specification reference to help Peter? Is there an ECMA or ISO specification effort for BD? Best regards, David Burg. -----Original Message----- From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Peter Van Hove Sent: Tuesday, October 10, 2006 8:30 AM To: t10 at t10.org Cc: mtfuji5 at avc-pioneer.com Subject: BD Dual Layer * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * How does one see how many layers a BD disc has ? BD-ROM, BD-R and BD-RE (blank and written) There are no specific features for it anymore, as was the case for DVD+R and DVD+RW And I can't find it via Read Disc Structure either ? I'm sure it's there somewhere ? :) I just keep looking over it probably ? . * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Alvin.Cox at seagate.com Tue Oct 10 14:54:37 2006 From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com) Date: Tue, 10 Oct 2006 16:54:37 -0500 Subject: SAS PHY WG coference call October 12, 2006 10 am CDT Message-ID: Formatted message: HTML-formatted message Next conference call October 12, 2006 Agenda: 1. 06-324 http://www.t10.org/ftp/t10/document.06/06-324r4.pdf 2. 10-meter cable specification 3. Identify PHY specifications items that affect EMI 4. New items PARTICIPANT INFORMATION: Toll Free Dial in Number: (866) 279-4742 International Access/Caller Paid Dial In Number: (309) 229-0118 PARTICIPANT CODE: 3243413 Webex information: https://seagate.webex.com/seagate Topic: SAS-2 PHY WG Date: Thursday, Oct 12, 2006 Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) Meeting number: 826 515 680 Meeting password: 6gbpsSAS Alvin Cox Seagate Technology, LLC Tel 405-350-7424 Cell 405-206-4809 From kenji.akahoshi.hr at hitachi.com Wed Oct 11 02:04:44 2006 From: kenji.akahoshi.hr at hitachi.com (Kenji Akahoshi) Date: Wed, 11 Oct 2006 18:04:44 +0900 Subject: About DVD-RW DL Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Kenji Akahoshi * Hello, Ai-san, Katata-san I have some questions about "MEI.pdf" and "DVD-RW DL.pdf". Ai-san, About Qs on DVD-RW DL MEI.pdf" Question 3. Could you tell me about this document? Q1. What is the ESN? End Sector Number? Is it means LRA or ERZ? Q2. Could you tell me about the disc status at the below condition? ----------------------------------------------- LRA is on L0.ERZ is on L1. ---------------------------------------------- In this condition, PLJA should be != 0? And if it is true, I think you need to add the another disc status. (ERZ is on L1 & PLJA != 0, ERZ is on L1 & PLJA = 0) ----------------------------------------------- LRA is on L1 "PLJA = 0 & LJA = 0" & "PLJA = 0 & LJA != 0" ---------------------------------------------- In this condition, why the "Logically recorded area on L1" is not "to LRA" but "to ERZ" ? Katata-san, I have some questions about "DVD-RW_DL.pdf(Revision 0.6)". Could you tell me about this document? Q1.About Figure 106 on page 248. "if user data is written on this condition of Buffer Block, the LRA moves to NWA-1" At the this condition, LRA is on L1(End of RZone end). So, I think "LRA != NWA-1". Q2.About "4.20.7.3 Non-contiguous condition" on page 255. In this paragraph, "The disc state may be Complete state." Why complete state? p.s. I'll attend tomorrow meeting. Best regards, --------------- Kenji Akahoshi HITCHI Ltd, * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From ai.takaharu at jp.panasonic.com Wed Oct 11 15:16:27 2006 From: ai.takaharu at jp.panasonic.com (Takaharu Ai) Date: Thu, 12 Oct 2006 07:16:27 +0900 Subject: About DVD-RW DL Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Takaharu Ai * Hello Akahoshi-san, First of all, I made two mistakes in the table. First one is the Incompete state must be Intermediate state, and the second one is that the description for the Disc Status of (LRA is on L0, and ERZ in on L1) must be "LRA is in 2nd LJB". >Q1. What is the ESN? End Sector Number? Is it means LRA or ERZ? ESN means "Maximum recorded sector number of the Data area" recorded in RW-physical format information. >Q2. Could you tell me about the disc status at the below condition? >----------------------------------------------- > >LRA is on L0.ERZ is on L1. >---------------------------------------------- >In this condition, PLJA should be != 0? Yes, you are correct. This condition is like as follows. ERZ v +----------+------------------------------------------------+---------+ |Lead-out |##########B |Fixed MA | +-------+--+------------------------------------------------+---------+ |Lead-in|#############B####### |Fixed MA | +-------+---------------------------------------------------+---------+ ^ ^ PLJA LRA where #:logically recorded area B:Buffer block >And if it is true, I think you need to add the another disc status. >(ERZ is on L1 & PLJA != 0, ERZ is on L1 & PLJA = 0) I am sorry but I may misunderstand. The first condition looks the RZone codition is non-contiguous and the first LJB is fully recorded. It is listed at the last three rows. The second condition looks Partially recorded contiguous because PLJA=0 means no layer jump has happened. In this condition, LRA and ERZ point the same location. This condition is (LRA is on L1, and PLJA = 0 & LJA = 0) in my table. >----------------------------------------------- > >LRA is on L1 >"PLJA = 0 & LJA = 0" & "PLJA = 0 & LJA != 0" >---------------------------------------------- >In this condition, >why the "Logically recorded area on L1" is not "to LRA" but "to ERZ" ? In those cases, LRA and ERZ point the same location, because no fully recoded LJB exists. So you can use LRA insrtead of ERZ. Best Regards, Harry Ai VEBU Panasonic AVC Networks Company Matsushita/Panasonic Osaka, Japan ---------------- Start of the original message ---------------- >From: Kenji Akahoshi >To: mtfuji5 at avc-pioneer.com >Cc: t10 at t10.org >Date: Wed, 11 Oct 2006 18:04:44 +0900 >Subject: About DVD-RW DL > >Hello, >Ai-san, Katata-san > >I have some questions about "MEI.pdf" and "DVD-RW DL.pdf". > >Ai-san, > >About Qs on DVD-RW DL MEI.pdf" Question 3. >Could you tell me about this document? > >Q1. What is the ESN? End Sector Number? Is it means LRA or ERZ? > >Q2. Could you tell me about the disc status at the below condition? >----------------------------------------------- > >LRA is on L0.ERZ is on L1. >---------------------------------------------- >In this condition, PLJA should be != 0? >And if it is true, I think you need to add the another disc status. >(ERZ is on L1 & PLJA != 0, ERZ is on L1 & PLJA = 0) > >----------------------------------------------- > >LRA is on L1 >"PLJA = 0 & LJA = 0" & "PLJA = 0 & LJA != 0" >---------------------------------------------- >In this condition, >why the "Logically recorded area on L1" is not "to LRA" but "to ERZ" ? > > >Katata-san, > >I have some questions about "DVD-RW_DL.pdf(Revision 0.6)". >Could you tell me about this document? > >Q1.About Figure 106 on page 248. >"if user data is written on this condition of Buffer Block, >the LRA moves to NWA-1" >At the this condition, LRA is on L1(End of RZone end). >So, I think "LRA != NWA-1". > >Q2.About "4.20.7.3 Non-contiguous condition" on page 255. >In this paragraph, "The disc state may be Complete state." >Why complete state? > > >p.s. I'll attend tomorrow meeting. > >Best regards, > >--------------- >Kenji Akahoshi >HITCHI Ltd, ----------------- End of the original message ----------------- * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Bob.Nixon at Emulex.Com Fri Oct 13 16:08:51 2006 From: Bob.Nixon at Emulex.Com (Bob.Nixon at Emulex.Com) Date: Fri, 13 Oct 2006 16:08:51 -0700 Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Dave, Despite the potential value of CISC to FCP operation in Class 3, we must advise against requiring or even recommending it. In our interoperability testing, we have discovered there are devices with significant installed base that do not behave properly when actually presented with CISC. Unfortunately, they do not reject an N_Port Login that offers CISC, so this problem is not discoverable. Even recommending CISC in a standard would therefore increase the incidence of interoperability problems with use of Fibre Channel. - Bob Nixon, Emulex alternate representative -----Original Message----- From: t11_3-bounces at listserve.com [mailto:t11_3-bounces at listserve.com]On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From Bob.Nixon at emulex.com Fri Oct 13 16:08:51 2006 From: Bob.Nixon at emulex.com (Bob.Nixon at emulex.com) Date: Fri, 13 Oct 2006 16:08:51 -0700 Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message Dave, Despite the potential value of CISC to FCP operation in Class 3, we must advise against requiring or even recommending it. In our interoperability testing, we have discovered there are devices with significant installed base that do not behave properly when actually presented with CISC. Unfortunately, they do not reject an N_Port Login that offers CISC, so this problem is not discoverable. Even recommending CISC in a standard would therefore increase the incidence of interoperability problems with use of Fibre Channel. - Bob Nixon, Emulex alternate representative -----Original Message----- From: t11_3-bounces at listserve.com [mailto:t11_3-bounces at listserve.com]On Behalf Of David Peterson Sent: Sunday, October 08, 2006 12:34 PM To: t10 at t10.org Cc: t11_3 at t11.org Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Howdy All, At the last FCP-4 working group meeting I presented a proposal to request the use of continuously increasing SEQ_CNT (CISC) for Class 3 service. While most believe requiring continuously increasing SEQ_CNT for Class 3 service is a good idea, one vendor indicated that none of their implementations support CISC, and another vendor was concerned about the requirement. As such, we have the following options: a. require CISC for Class 3 service. This means that existing implementations can claim compliance to a prior standard (e.g., FCP-3); b. specify that CISC should be used for Class 3 service; c. no change (i.e., CISC is not required except for streamed Sequences). My preference would be option a. What say ye? ...Dave (no disclaimer) From daviburg at windows.microsoft.com Fri Oct 13 22:05:28 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Fri, 13 Oct 2006 22:05:28 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: Formatted message: HTML-formatted message Hello, During validation of DVD-ROM devices conformance to the MMC command set through the Windows Vista Logo program and MMCTest tool, we were signaled the possible flaw in either our tool or the specification. Our tool query from the drive the list of profiles supported by the drive, and then exercises each of the profiles. Some ROM drives will also report R and/or RW profiles. Thus our tool attempts to validate these profiles, and as part of the validation attempts to validate that the drive recognize blank media properly. Yes, blank media. I understand that hardware manufacturers may very well be reluctant to guarantee this capability on ROM drives. The value of recognizing blank media in a ROM drive that won't be able to write it is also questionable. However there are also positives aspects: a ROM drive able to recognize the blank media will not spin un-definitively in attempt to find a track, it will further be capable to report that the media is blank to the host so that the host software may report the issue to the user and help him to correct his mistake. Clearly some ROM drives do not support recognizing blank recordable or rewritable media, even sometimes do not recognize recorded recordable or rewritable media. So the question is: Does reporting R and/or RW/Rewritable profile by a drive mandate that it is capable of recognizing the matching blank R and/or RW/Rewritable profile? Best regards, David Burg, Microsoft Corporation. From kdbutt at us.ibm.com Sat Oct 14 08:58:24 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Sat, 14 Oct 2006 08:58:24 -0700 Subject: SSC-3: TapeAlert enhancements (06-138r2) Message-ID: Formatted message: HTML-formatted message My proposal on TapeAlert enhancements has been uploaded. This is a new approach with a lot of information. I would appreciate any feedback that would help me understand if this approach would be acceptable. 2006/10/14 03:40:31 Your request to upload a file or files to the T10 site has been accepted. Your PDF file will be posted at: http://www.t10.org/ftp/t10/document.06/06-138r2.pdf Normally, the posting/archiving process takes about 30 minutes. Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com From lohmeyer at t10.org Sat Oct 14 23:02:56 2006 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 15 Oct 2006 00:02:56 -0600 Subject: Recent T10 documents uploaded since 2006/10/08 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SSC-3: TapeAlert Delineation (by: Kevin Butt) T10/06-138r2 Uploaded: 2006/10/14 236807 bytes ftp://ftp.t10.org/t10/document.06/06-138r2.pdf SAS-2 Modifications to the SAS Speed Negotiation (by: Stephen Finch, Amr Wassal) T10/06-324r5 Uploaded: 2006/10/12 335316 bytes ftp://ftp.t10.org/t10/document.06/06-324r5.pdf Security Association Model for SPC-4 (by: Ralph O. Weber) T10/06-369r5 Uploaded: 2006/10/09 89000 bytes ftp://ftp.t10.org/t10/document.06/06-369r5.pdf SPC-4: Security Goals and Threat Model (by: David L. Black) T10/06-388r2 Uploaded: 2006/10/13 45175 bytes ftp://ftp.t10.org/t10/document.06/06-388r2.pdf SPC-4: Security Goals and Threat Model (by: David L. Black) T10/06-388r2 Uploaded: 2006/10/13 10451 bytes ftp://ftp.t10.org/t10/document.06/06-388r2.txt Using Public-Key Cryptography for Key Wrapping (by: Gideon Avida) T10/06-389r1 Uploaded: 2006/10/13 70075 bytes ftp://ftp.t10.org/t10/document.06/06-389r1.pdf Minutes of FCP-4 Working Group - September 12, 2006 (by: Bob Nixon) T10/06-428r2 Uploaded: 2006/10/11 26553 bytes ftp://ftp.t10.org/t10/document.06/06-428r2.pdf SC25 2006 Documents (by: Gary S. Robinson) T10/06-450r0 Uploaded: 2006/10/10 19482 bytes ftp://ftp.t10.org/t10/document.06/06-450r0.pdf SAS-2: Miscellaneous State Machine Fixes (by: George O. Penokie) T10/06-451r0 Uploaded: 2006/10/09 100723 bytes ftp://ftp.t10.org/t10/document.06/06-451r0.pdf Lost SET IDENTIFYING INFORMATION Parameter List Length requirement (by: Ralph O. Weber) T10/06-455r1 Uploaded: 2006/10/10 19687 bytes ftp://ftp.t10.org/t10/document.06/06-455r1.pdf Working Drafts -------------- SCSI Media Changer Command Set - 3 (SMC-3) (Editor: Noud Snelder) Rev: 04 Uploaded: 2006/10/10 1815862 bytes ftp://ftp.t10.org/t10/drafts/smc3/smc3r04.pdf (Report generated on 2006/10/15 at 00:02:55) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From keiji_katata at post.pioneer.co.jp Sun Oct 15 23:47:09 2006 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Mon, 16 Oct 2006 15:47:09 +0900 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hi David, ----- Question ----- So the question is: Does reporting R and/or RW/Rewritable profile by a drive mandate that it is capable of recognizing the matching blank R and/or RW/Rewritable profile? ------------------- I think it is yes. All commands listed in the Features those are listed in the Profile shall work correctly. So for example, CD-R profile requests "Incremental Streaming Writable Feature" and "CD Track at Once Feature". These Features request READ DISC INFORMATION command and READ TRACK INFORMATION command. Those information must be reported from any condition of the CD-R disc except fatal error condition of the drive. I think Blank condition of CD-R is normal condition of the disc. On the other hand, these Feature request "This Feature identifies a Drive that is able to write data". Therefore ROM drive shall not report the supporting of there Features. Then ROM drive cannot report CD-R profile. Best regards, Keiji Katata PIONEER CORP. David Burg @avc-pioneer.com on 2006/10/14 14:05:28 mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B $BAw?., cc: Bhanu Gogineni , Ahmed Tolba bcc: $B7oL>(B: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Hello, During validation of DVD-ROM devices conformance to the MMC command set through the Windows Vista Logo program and MMCTest tool, we were signaled the possible flaw in either our tool or the specification. Our tool query from the drive the list of profiles supported by the drive, and then exercises each of the profiles. Some ROM drives will also report R and/or RW profiles. Thus our tool attempts to validate these profiles, and as part of the validation attempts to validate that the drive recognize blank media properly. Yes, blank media. I understand that hardware manufacturers may very well be reluctant to guarantee this capability on ROM drives. The value of recognizing blank media in a ROM drive that won$B!G(Bt be able to write it is also questionable. However there are also positives aspects: a ROM drive able to recognize the blank media will not spin un-definitively in attempt to find a track, it will further be capable to report that the media is blank to the host so that the host software may report the issue to the user and help him to correct his mistake. Clearly some ROM drives do not support recognizing blank recordable or rewritable media, even sometimes do not recognize recorded recordable or rewritable media. So the question is: Does reporting R and/or RW/Rewritable profile by a drive mandate that it is capable of recognizing the matching blank R and/or RW/Rewritable profile? Best regards, David Burg, Microsoft Corporation. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From craig.carlson at qlogic.com Mon Oct 16 08:19:13 2006 From: craig.carlson at qlogic.com (Craig W. Carlson) Date: Mon, 16 Oct 2006 10:19:13 -0500 Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message I?d have to agree with Bob on this one. We are aware of devices which cannot support CISC, and which would seriously break if presented with it. A change such as this (either a or b) could create havoc with device interoperability. +Craig On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" wrote: > Dave, > > Despite the potential value of CISC to FCP operation in Class 3, we must > advise against requiring or even recommending it. > > In our interoperability testing, we have discovered there are devices with > significant installed base that do not behave properly when actually presented > with CISC. Unfortunately, they do not reject an N_Port Login that offers > CISC, so this problem is not discoverable. > > Even recommending CISC in a standard would therefore increase the incidence of > interoperability problems with use of Fibre Channel. > > - Bob Nixon, Emulex alternate representative > > -----Original Message----- > From: t11_3-bounces at listserve.com [mailto:t11_3-bounces at listserve.com]On > Behalf Of David Peterson > Sent: Sunday, October 08, 2006 12:34 PM > To: t10 at t10.org > Cc: t11_3 at t11.org > Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT > > Howdy All, > > At the last FCP-4 working group meeting I presented a proposal to request the > use of continuously increasing SEQ_CNT (CISC) for Class 3 service. > > While most believe requiring continuously increasing SEQ_CNT for Class 3 > service is a good idea, one vendor indicated that none of their > implementations support CISC, and another vendor was concerned about the > requirement. > > As such, we have the following options: > > a. require CISC for Class 3 service. This means that existing implementations > can claim compliance to a prior standard (e.g., FCP-3); > b. specify that CISC should be used for Class 3 service; > c. no change (i.e., CISC is not required except for streamed Sequences). > > My preference would be option a. > > What say ye? > > ...Dave > > (no disclaimer) > > > > > _______________________________________________ > T11_3 mailing list > http://mailman.listserve.com/listmanager/listinfo/t11_3 ------------------------------------------------------------------ Craig W. Carlson mailto:craig.carlson at qlogic.com QLogic Corporation (952) 932-4064 6321 Bury Drive Eden Prairie, MN 55346 From craig.carlson at qlogic.com Mon Oct 16 08:19:13 2006 From: craig.carlson at qlogic.com (Craig W. Carlson) Date: Mon, 16 Oct 2006 10:19:13 -0500 Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT Message-ID: Formatted message: HTML-formatted message I?d have to agree with Bob on this one. We are aware of devices which cannot support CISC, and which would seriously break if presented with it. A change such as this (either a or b) could create havoc with device interoperability. +Craig On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" wrote: > Dave, > > Despite the potential value of CISC to FCP operation in Class 3, we must > advise against requiring or even recommending it. > > In our interoperability testing, we have discovered there are devices with > significant installed base that do not behave properly when actually presented > with CISC. Unfortunately, they do not reject an N_Port Login that offers > CISC, so this problem is not discoverable. > > Even recommending CISC in a standard would therefore increase the incidence of > interoperability problems with use of Fibre Channel. > > - Bob Nixon, Emulex alternate representative > > -----Original Message----- > From: t11_3-bounces at listserve.com [mailto:t11_3-bounces at listserve.com]On > Behalf Of David Peterson > Sent: Sunday, October 08, 2006 12:34 PM > To: t10 at t10.org > Cc: t11_3 at t11.org > Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT > > Howdy All, > > At the last FCP-4 working group meeting I presented a proposal to request the > use of continuously increasing SEQ_CNT (CISC) for Class 3 service. > > While most believe requiring continuously increasing SEQ_CNT for Class 3 > service is a good idea, one vendor indicated that none of their > implementations support CISC, and another vendor was concerned about the > requirement. > > As such, we have the following options: > > a. require CISC for Class 3 service. This means that existing implementations > can claim compliance to a prior standard (e.g., FCP-3); > b. specify that CISC should be used for Class 3 service; > c. no change (i.e., CISC is not required except for streamed Sequences). > > My preference would be option a. > > What say ye? > > ...Dave > > (no disclaimer) > > > > > _______________________________________________ > T11_3 mailing list > http://mailman.listserve.com/listmanager/listinfo/t11_3 ------------------------------------------------------------------ Craig W. Carlson mailto:craig.carlson at qlogic.com QLogic Corporation (952) 932-4064 6321 Bury Drive Eden Prairie, MN 55346 From michael.banther at hp.com Mon Oct 16 07:55:35 2006 From: michael.banther at hp.com (Banther, Michael) Date: Mon, 16 Oct 2006 15:55:35 +0100 Subject: SSC-3: Thoughts about making ADC Log Page 11h common to SSC-3? Message-ID: Formatted message: HTML-formatted message Attachment #1: banther_michael.vcf Hi Kevin, HP will support bringing log page 11h into SSC-3. We also would like to see log page 13h brought into SSC-3. Regards, Michael Banther Hewlett-Packard Ltd. +44 117 312 9503 ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt Sent: 15 August 2006 20:10 To: t10 at t10.org Subject: SSC-3: Thoughts about making ADC Log Page 11h common to SSC-3? All, I would like to get a sense of what the communities feelings are about making ADC Log Page 11h (DT Device Status log page) a log page in SSC-3. I have had many requests for this type of information to be available over the primary port and I think this would be the best way to handle it. I would think the proposal would be on the order of referring SSC-3 to ADC-2 for the description of the Log Page. Any comments would be appreciated. Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com http://www-03.ibm.com/servers/storage/ From kdbutt at us.ibm.com Mon Oct 16 11:03:33 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Mon, 16 Oct 2006 12:03:33 -0600 Subject: SSC-3: Thoughts about making ADC Log Page 11h common to SSC-3? Message-ID: Formatted message: HTML-formatted message Attachment #1: banther_michael.vcf Michael. Log page 11h is already in SSC-3. See Table 56 ? Log page codes in 8.2.1. Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com http://www-03.ibm.com/servers/storage/ "Banther, Michael" Sent by: owner-t10 at t10.org 10/16/2006 07:55 AM To Kevin D Butt/Tucson/IBM at IBMUS cc Subject RE: SSC-3: Thoughts about making ADC Log Page 11h common to SSC-3? Hi Kevin, HP will support bringing log page 11h into SSC-3. We also would like to see log page 13h brought into SSC-3. Regards, Michael Banther Hewlett-Packard Ltd. +44 117 312 9503 From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt Sent: 15 August 2006 20:10 To: t10 at t10.org Subject: SSC-3: Thoughts about making ADC Log Page 11h common to SSC-3? All, I would like to get a sense of what the communities feelings are about making ADC Log Page 11h (DT Device Status log page) a log page in SSC-3. I have had many requests for this type of information to be available over the primary port and I think this would be the best way to handle it. I would think the proposal would be on the order of referring SSC-3 to ADC-2 for the description of the Log Page. Any comments would be appreciated. Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com http://www-03.ibm.com/servers/storage/ From daviburg at windows.microsoft.com Mon Oct 16 11:10:51 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Mon, 16 Oct 2006 11:10:51 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Hello Katata-san, Thank you for your answer. Your analysis is correct, in particular for CD and DVD dash where the said profile requests write features to be supported. But remains the particularity of the DVD plus command set, where the profile does not request write features to be supported unless the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is always mandatory, and this one includes the same READ DISC INFORMATION you mention. Best regards, David Burg. -----Original Message----- From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of keiji_katata at post.pioneer.co.jp Sent: Sunday, October 15, 2006 11:47 PM To: mtfuji5 at avc-pioneer.com Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Hi David, ----- Question ----- So the question is: Does reporting R and/or RW/Rewritable profile by a drive mandate that it is capable of recognizing the matching blank R and/or RW/Rewritable profile? ------------------- I think it is yes. All commands listed in the Features those are listed in the Profile shall work correctly. So for example, CD-R profile requests "Incremental Streaming Writable Feature" and "CD Track at Once Feature". These Features request READ DISC INFORMATION command and READ TRACK INFORMATION command. Those information must be reported from any condition of the CD-R disc except fatal error condition of the drive. I think Blank condition of CD-R is normal condition of the disc. On the other hand, these Feature request "This Feature identifies a Drive that is able to write data". Therefore ROM drive shall not report the supporting of there Features. Then ROM drive cannot report CD-R profile. Best regards, Keiji Katata PIONEER CORP. David Burg @avc-pioneer.com on 2006/10/14 14:05:28 mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J $BAw?., cc: Bhanu Gogineni , Ahmed Tolba bcc: $B7oL>(J: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Hello, During validation of DVD-ROM devices conformance to the MMC command set through the Windows Vista Logo program and MMCTest tool, we were signaled the possible flaw in either our tool or the specification. Our tool query from the drive the list of profiles supported by the drive, and then exercises each of the profiles. Some ROM drives will also report R and/or RW profiles. Thus our tool attempts to validate these profiles, and as part of the validation attempts to validate that the drive recognize blank media properly. Yes, blank media. I understand that hardware manufacturers may very well be reluctant to guarantee this capability on ROM drives. The value of recognizing blank media in a ROM drive that won$B!G(Jt be able to write it is also questionable. However there are also positives aspects: a ROM drive able to recognize the blank media will not spin un-definitively in attempt to find a track, it will further be capable to report that the media is blank to the host so that the host software may report the issue to the user and help him to correct his mistake. Clearly some ROM drives do not support recognizing blank recordable or rewritable media, even sometimes do not recognize recorded recordable or rewritable media. So the question is: Does reporting R and/or RW/Rewritable profile by a drive mandate that it is capable of recognizing the matching blank R and/or RW/Rewritable profile? Best regards, David Burg, Microsoft Corporation. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From kdbutt at us.ibm.com Mon Oct 16 11:33:01 2006 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Mon, 16 Oct 2006 11:33:01 -0700 Subject: Comments on 06-369r5: Security Association Model for SPC-4 Message-ID: Formatted message: HTML-formatted message Ralph and all, To reiterate the position of IBM Tape related to 06-369r5: Security Association Model for SPC-4, we see the need for the items in this proposal but we object to the proposals acceptance until there is a "Security protocol that creates SAs". The proposal as it stands today, has a table for these Security protocols that create an SA, but there is only a TBD. We fear that passing this proposal without a Security protocol defined that creates an SA, will open the door for items that rely on SAs to be added to the standard prior to any method to create an SA. We believe that this would work against the attempts to standardize methods of creating an SA, because vendors will begin creating SAs with vendor-specific methods in order to get the items that rely on an SA. Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com From roweber at IEEE.org Mon Oct 16 12:54:15 2006 From: roweber at IEEE.org (Ralph Weber) Date: Mon, 16 Oct 2006 14:54:15 -0500 Subject: Comments on 06-369r5: Security Association Model for SPC-4 Message-ID: Formatted message: HTML-formatted message Kevin, The proposal you are looking for is 06-449 (SPC-4: Establishing a Security Association using ...). I am working with the proposal authors regarding SCSI details at this time. Whether both proposals will be ready for approval during the same meeting week is anybody's guess. Regardless, I intend to move for approval of 06-369r? whenever it is technically complete. I anticipate that SPC-4 will include a full complement of SA-related topics before it is sent to Letter Ballot. All the best, .Ralph Kevin D Butt wrote: > > Ralph and all, > > To reiterate the position of IBM Tape related to 06-369r5: Security > Association Model for SPC-4, we see the need for the items in this > proposal but we object to the proposals acceptance until there is a > "Security protocol that creates SAs". The proposal as it stands > today, has a table for these Security protocols that create an SA, but > there is only a TBD. We fear that passing this proposal without a > Security protocol defined that creates an SA, will open the door for > items that rely on SAs to be added to the standard prior to any method > to create an SA. We believe that this would work against the attempts > to standardize methods of creating an SA, because vendors will begin > creating SAs with vendor-specific methods in order to get the items > that rely on an SA. > > Thanks, > > Kevin D. Butt > SCSI & Fibre Channel Architect, Tape Firmware > MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 > Tel: 520-799-2869 / 520-799-5280 > Fax: 520-799-2723 (T/L:321) > Email address: kdbutt at us.ibm.com > http://www-03.ibm.com/servers/storage/ From Peter at Smart-Projects.net Mon Oct 16 13:25:35 2006 From: Peter at Smart-Projects.net (Peter Van Hove) Date: Mon, 16 Oct 2006 22:25:35 +0200 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * Dear David, All, I hope I'm not completely missing the point but for DVD+R/W the way I understand it is the following. Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles (and hence also no features), then a modern drive will likely have no issues with DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs and blank media will likely not be seen as such. Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a host must still request the relevant features to see if that drive is able to write also in addition to reading the media. Since the ROM drive can't write, the write bit will be set to zero. All this means is a "guarantee" that +RW media is properly recognised, nothing more. MMC says: "This feature may be present only to represent additional capability to the DVD-ROM Profile. If the Write bit is set to zero, then no additional capability is claimed." I understand "then no additional capability is claimed." as compared to the DVD-ROM profile. The DVD-ROM profile's "interesting" feature is the DVD Read feature. The DVD read feature does not include the "READ DISC INFORMATION" command. In other words, a ROM drive that supports the DVD+ profiles and features, but doesn't support the write bit to one, does no more than a DVD-ROM drive without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee that DVD+R/W is supported *EVEN* when the booktype is still the original booktype, and not the DVD-ROM booktype that is often used for compatibility. I could be wrong, but this is how I understand it. PS., also from MMC (for the DVD+R feature for instance) "If a Drive reports this feature with the Write bit set to one and the Current bit set to one, then it shall support the commands shown in table ..... " So only when the write bit is set to one additonal commands are supported, including: the "READ DISC INFORMATION" command Best Regards, Peter ------------------------------------------------------- Peter Van Hove www.Smart-Projects.net www.IsoBuster.com ------------------------------------------------------- ------------------------------------------------------- ----- Original Message ----- From: "David Burg" To: Cc: ; "Bhanu Gogineni" ; "Ahmed Tolba" Sent: Monday, October 16, 2006 8:10 PM Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >* From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Hello Katata-san, > > Thank you for your answer. Your analysis is correct, in particular for CD > and DVD dash where the said profile requests write features to be > supported. But remains the particularity of the DVD plus command set, > where the profile does not request write features to be supported unless > the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is > always mandatory, and this one includes the same READ DISC INFORMATION you > mention. > > Best regards, > > David Burg. > > -----Original Message----- > From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] > On Behalf Of keiji_katata at post.pioneer.co.jp > Sent: Sunday, October 15, 2006 11:47 PM > To: mtfuji5 at avc-pioneer.com > Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > > Hi David, > > ----- Question ----- > So the question is: Does reporting R and/or RW/Rewritable profile by a > drive > mandate that it is capable of recognizing the matching blank R and/or > RW/Rewritable profile? > ------------------- > I think it is yes. All commands listed in the Features those are listed in > the > Profile shall work correctly. So for example, CD-R profile requests > "Incremental > Streaming Writable Feature" and "CD Track at Once Feature". These Features > request READ DISC INFORMATION command and READ TRACK INFORMATION command. > Those > information must be reported from any condition of the CD-R disc except > fatal > error condition of the drive. I think Blank condition of CD-R is normal > condition of the disc. > > On the other hand, these Feature request "This Feature identifies a Drive > that > is able to write data". Therefore ROM drive shall not report the > supporting of > there Features. Then ROM drive cannot report CD-R profile. > > Best regards, > > Keiji Katata > PIONEER CORP. > > > > > > David Burg @avc-pioneer.com on 2006/10/14 > 14:05:28 > > mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B > > $BAw?. > > > > $B08 at h(B: , > cc: Bhanu Gogineni , Ahmed Tolba > > bcc: > $B7oL>(B: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Hello, > > During validation of DVD-ROM devices conformance to the MMC command set > through > the Windows Vista Logo program and MMCTest tool, we were signaled the > possible > flaw in either our tool or the specification. Our tool query from the > drive the > list of profiles supported by the drive, and then exercises each of the > profiles. Some ROM drives will also report R and/or RW profiles. Thus our > tool > attempts to validate these profiles, and as part of the validation > attempts to > validate that the drive recognize blank media properly. > > Yes, blank media. I understand that hardware manufacturers may very well > be > reluctant to guarantee this capability on ROM drives. The value of > recognizing > blank media in a ROM drive that won$B!G(Bt be able to write it is also > questionable. > However there are also positives aspects: a ROM drive able to recognize > the > blank media will not spin un-definitively in attempt to find a track, it > will > further be capable to report that the media is blank to the host so that > the > host software may report the issue to the user and help him to correct his > mistake. > > Clearly some ROM drives do not support recognizing blank recordable or > rewritable media, even sometimes do not recognize recorded recordable or > rewritable media. > > So the question is: Does reporting R and/or RW/Rewritable profile by a > drive > mandate that it is capable of recognizing the matching blank R and/or > RW/Rewritable profile? > > Best regards, > > David Burg, > Microsoft Corporation. > > > > > > > > > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From billmc37 at ctesc.net Mon Oct 16 14:53:47 2006 From: billmc37 at ctesc.net (Bill McFerrin) Date: Mon, 16 Oct 2006 16:53:47 -0500 Subject: CDM? Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Bill McFerrin * Hello T10 world, We hear that something called the Common Diagnostic Model (CDM) has gained interest. It appears to be mostly a network and software "thing", but is anyone aware of device/command requirements? Thank you, Bill McFerrin and MMC * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Dennis.Pak at am.sony.com Mon Oct 16 16:28:11 2006 From: Dennis.Pak at am.sony.com (Pak, Dennis) Date: Mon, 16 Oct 2006 16:28:11 -0700 Subject: CDM? Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Pak, Dennis" * Hi Bill, The Common Diagnostic Model is an "OS independent" diagnostic framework that defines a standard interface for diagnostic modules. However, the standard doesn't define component level diagnostic commands. You can get more info at the following web site: http://www.dmtf.org The group is promoting a Management Developers Conference (MDC) on December 4 - 7, 2006 in Santa Clara, CA, but the conference is not free. There should be members of Forum Leadership companies on this reflector. Hopefully, they can also add more info. Regards, <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< Dennis Pak <>< Advanced Storage Development <>< Component Solutions Business Division (CSBD) <>< Sony Electronics Inc. <>< phone: (408)955-5247 <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< -----Original Message----- From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin Sent: Monday, October 16, 2006 2:54 PM To: T10 Reflector Subject: CDM? * From the T10 Reflector (t10 at t10.org), posted by: * Bill McFerrin * Hello T10 world, We hear that something called the Common Diagnostic Model (CDM) has gained interest. It appears to be mostly a network and software "thing", but is anyone aware of device/command requirements? Thank you, Bill McFerrin and MMC * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From takeshi_kohda at post.pioneer.co.jp Tue Oct 17 00:26:13 2006 From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp) Date: Tue, 17 Oct 2006 16:26:13 +0900 Subject: October Mt. Fuji meeting minutes Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * takeshi_kohda at post.pioneer.co.jp * Dear all, October Mt. Fuji meeting minutes are made available on the following URL: ftp://ftp.avc-pioneer.com/Mtfuji_7/Minutes/MinOct06.pdf Best regards, --- Takeshi Kohda * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Alvin.Cox at seagate.com Tue Oct 17 06:53:53 2006 From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com) Date: Tue, 17 Oct 2006 08:53:53 -0500 Subject: Special item for SAS PHY teleconference this Thursday Message-ID: Formatted message: HTML-formatted message Question came up regarding the OOB requirement for OOB for all future speeds. This topic will be discussed as the first item on the next call. Reasons for 1.5Gbps OOB: OOB detection typically done with separate circuitry. OOB circuitry benefits from 1.5Gbps limit. 1.5Gbps is easier to send through the channel and has less loss than higher frequencies. Also does not require equalization for recovery. SATA requires 1.5Gbps OOB, so the capability at 1.5Gbps is necessary for compatibility of PHY's that attach to SATA. I realize this is only one side of the argument, but these are some of the reasons why the statement is there. The discussion should cover both sides of the situation. Next conference call October 19, 2006 Agenda: 1. OOB signals to be 1,5 Gbps for all future implementations? 2. http://www.t10.org/ftp/t10/document.06/06-324r5.pdf 3. New items PARTICIPANT INFORMATION: Toll Free Dial in Number: (866) 279-4742 International Access/Caller Paid Dial In Number: (309) 229-0118 PARTICIPANT CODE: 3243413 Webex information: https://seagate.webex.com/seagate Topic: SAS-2 PHY WG Date: Thursday, Oct 19, 2006 Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) Meeting number: 826 515 680 Meeting password: 6gbpsSAS Minutes from last week posted at. No real details except as above. http://www.t10.org/ftp/t10/document.06/06-457r0.pdf Alvin Cox Seagate Technology, LLC Tel 405-350-7424 Cell 405-206-4809 From daviburg at windows.microsoft.com Tue Oct 17 13:30:11 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Tue, 17 Oct 2006 13:30:11 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Dear Peter, All, If I correctly understand your analysis, you analyzed the capabilities claim |from the DVD+R/W *feature(s)*. And in the paragraph which you quoted for "This feature may be present only to represent additional capability to the DVD-ROM Profile. If the Write bit is set to zero, then no additional capability is claimed.", is also said eventually "A device may report this feature only when Profile 10h (DVD-ROM) is reported. No additional commands or mode parameters are required." I am working on drives that reports the DVD+R/RW *profile*, not only the feature. And in the profile definition, the additional commands support is listed as mandatory. ("Drives identifying Profile 001Ah as current shall support the features listed in Table 221.") Would it be correct then to say that a DVD-ROM that want to claim only recognition of DVD+R/RW but *not* of additional commands has to list only the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the DVD+R/RW profile(s)? I still don't know actually if this would mean that blank DVD+R/RW media are recognized or not. As the MMC specification does not make a distinction in the support of DVD+R/RW between blank and recorded media, would it be correct to claim that devices claiming DVD+R/RW support have to support blank DVD+R/RW also? Best regards, David Burg, Microsoft. -----Original Message----- From: Peter Van Hove [mailto:Peter at Smart-Projects.net] Sent: Monday, October 16, 2006 1:26 PM To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Dear David, All, I hope I'm not completely missing the point but for DVD+R/W the way I understand it is the following. Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles (and hence also no features), then a modern drive will likely have no issues with DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs and blank media will likely not be seen as such. Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a host must still request the relevant features to see if that drive is able to write also in addition to reading the media. Since the ROM drive can't write, the write bit will be set to zero. All this means is a "guarantee" that +RW media is properly recognised, nothing more. MMC says: "This feature may be present only to represent additional capability to the DVD-ROM Profile. If the Write bit is set to zero, then no additional capability is claimed." I understand "then no additional capability is claimed." as compared to the DVD-ROM profile. The DVD-ROM profile's "interesting" feature is the DVD Read feature. The DVD read feature does not include the "READ DISC INFORMATION" command. In other words, a ROM drive that supports the DVD+ profiles and features, but doesn't support the write bit to one, does no more than a DVD-ROM drive without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee that DVD+R/W is supported *EVEN* when the booktype is still the original booktype, and not the DVD-ROM booktype that is often used for compatibility. I could be wrong, but this is how I understand it. PS., also from MMC (for the DVD+R feature for instance) "If a Drive reports this feature with the Write bit set to one and the Current bit set to one, then it shall support the commands shown in table ..... " So only when the write bit is set to one additonal commands are supported, including: the "READ DISC INFORMATION" command Best Regards, Peter ------------------------------------------------------- Peter Van Hove www.Smart-Projects.net www.IsoBuster.com ------------------------------------------------------- ------------------------------------------------------- ----- Original Message ----- From: "David Burg" To: Cc: ; "Bhanu Gogineni" ; "Ahmed Tolba" Sent: Monday, October 16, 2006 8:10 PM Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >* From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Hello Katata-san, > > Thank you for your answer. Your analysis is correct, in particular for CD > and DVD dash where the said profile requests write features to be > supported. But remains the particularity of the DVD plus command set, > where the profile does not request write features to be supported unless > the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is > always mandatory, and this one includes the same READ DISC INFORMATION you > mention. > > Best regards, > > David Burg. > > -----Original Message----- > From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] > On Behalf Of keiji_katata at post.pioneer.co.jp > Sent: Sunday, October 15, 2006 11:47 PM > To: mtfuji5 at avc-pioneer.com > Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > > Hi David, > > ----- Question ----- > So the question is: Does reporting R and/or RW/Rewritable profile by a > drive > mandate that it is capable of recognizing the matching blank R and/or > RW/Rewritable profile? > ------------------- > I think it is yes. All commands listed in the Features those are listed in > the > Profile shall work correctly. So for example, CD-R profile requests > "Incremental > Streaming Writable Feature" and "CD Track at Once Feature". These Features > request READ DISC INFORMATION command and READ TRACK INFORMATION command. > Those > information must be reported from any condition of the CD-R disc except > fatal > error condition of the drive. I think Blank condition of CD-R is normal > condition of the disc. > > On the other hand, these Feature request "This Feature identifies a Drive > that > is able to write data". Therefore ROM drive shall not report the > supporting of > there Features. Then ROM drive cannot report CD-R profile. > > Best regards, > > Keiji Katata > PIONEER CORP. > > > > > > David Burg @avc-pioneer.com on 2006/10/14 > 14:05:28 > > mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J > > $BAw?. > > > > $B08 at h(J: , > cc: Bhanu Gogineni , Ahmed Tolba > > bcc: > $B7oL>(J: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Hello, > > During validation of DVD-ROM devices conformance to the MMC command set > through > the Windows Vista Logo program and MMCTest tool, we were signaled the > possible > flaw in either our tool or the specification. Our tool query from the > drive the > list of profiles supported by the drive, and then exercises each of the > profiles. Some ROM drives will also report R and/or RW profiles. Thus our > tool > attempts to validate these profiles, and as part of the validation > attempts to > validate that the drive recognize blank media properly. > > Yes, blank media. I understand that hardware manufacturers may very well > be > reluctant to guarantee this capability on ROM drives. The value of > recognizing > blank media in a ROM drive that won$B!G(Jt be able to write it is also > questionable. > However there are also positives aspects: a ROM drive able to recognize > the > blank media will not spin un-definitively in attempt to find a track, it > will > further be capable to report that the media is blank to the host so that > the > host software may report the issue to the user and help him to correct his > mistake. > > Clearly some ROM drives do not support recognizing blank recordable or > rewritable media, even sometimes do not recognize recorded recordable or > rewritable media. > > So the question is: Does reporting R and/or RW/Rewritable profile by a > drive > mandate that it is capable of recognizing the matching blank R and/or > RW/Rewritable profile? > > Best regards, > > David Burg, > Microsoft Corporation. > > > > > > > > > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Peter at Smart-Projects.net Tue Oct 17 14:18:48 2006 From: Peter at Smart-Projects.net (Peter Van Hove) Date: Tue, 17 Oct 2006 23:18:48 +0200 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Peter Van Hove" * Dear David, All, > If I correctly understand your analysis, you analyzed the capabilities > claim from the DVD+R/W *feature(s)*. I mentioned both, as both can only live together. If the plus profile is reported the plus features will be present as well. > "A device may report this feature only when Profile 10h (DVD-ROM) is > reported" Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. I interpret that as, a drive must be a DVD ROM capable drive to be able to do DVD+R/W. > And in the profile definition, the additional commands support is listed > as mandatory. ("Drives identifying Profile 001Ah as current shall support > the features listed in Table 221.") I'm not using the same rev as you do, as it's table 220 in my spec :) But I'm not sure what you mean ? All it says is what features should be supported. And the features that are write related have a small uppercase 1 next to them, indicating: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." So the presence of the plus R/W profiles does not guarantee the availability of features that deal with writing, only those that deal with reading. And hence no guarantee that commands such as "Read Disc Information" are supported, which you need to be able to recognize blank media. > Would it be correct then to say that a DVD-ROM that want to claim only > recognition of DVD+R/RW but *not* of additional commands has to list only > the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the > DVD+R/RW profile(s)? I think that a DVD-ROM drive that either does or doesn't support the +R/W profiles (and features) doesn't need to support the special commands that you need to determine blank media. > I still don't know actually if this would mean that blank DVD+R/RW media > are recognized or not. Bet on the fact that 99% of the ROM drives won't see blank media. And the availability of plus R/RW features and profiles is no indication nor guarantee that the drive can recognise blank media. > would it be correct to claim that devices claiming DVD+R/RW support have > to support blank DVD+R/RW also? No, only if they set the write bit to one. Best Regards, Peter ------------------------------------------------------- Peter Van Hove, CEO Smart Projects CD and DVD Data recovery Peter at Smart-Projects.net www.Smart-Projects.net www.IsoBuster.com ------------------------------------------------------- ----- Original Message ----- From: "David Burg" To: "Peter Van Hove" ; ; Sent: Tuesday, October 17, 2006 10:30 PM Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > Dear Peter, All, > > If I correctly understand your analysis, you analyzed the capabilities > claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted > for "This feature may be present only to represent additional capability > to the > DVD-ROM Profile. If the Write bit is set to zero, then no additional > capability is claimed.", is also said eventually "A device may report this > feature only when Profile 10h (DVD-ROM) is reported. No additional > commands or mode parameters are required." > > I am working on drives that reports the DVD+R/RW *profile*, not only the > feature. And in the profile definition, the additional commands support is > listed as mandatory. ("Drives identifying Profile 001Ah as current shall > support the features listed in Table 221.") > > Would it be correct then to say that a DVD-ROM that want to claim only > recognition of DVD+R/RW but *not* of additional commands has to list only > the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the > DVD+R/RW profile(s)? > > I still don't know actually if this would mean that blank DVD+R/RW media > are recognized or not. As the MMC specification does not make a > distinction in the support of DVD+R/RW between blank and recorded media, > would it be correct to claim that devices claiming DVD+R/RW support have > to support blank DVD+R/RW also? > > Best regards, > > David Burg, > Microsoft. > > -----Original Message----- > From: Peter Van Hove [mailto:Peter at Smart-Projects.net] > Sent: Monday, October 16, 2006 1:26 PM > To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Dear David, All, > > I hope I'm not completely missing the point but > for DVD+R/W the way I understand it is the following. > > Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles > (and > hence also no features), then a modern drive will likely have no issues > with > DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs > and > blank media will likely not be seen as such. > > Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a > host must still request the relevant features to see if that drive is able > to write also in addition to reading the media. Since the ROM drive can't > write, the write bit will be set to zero. > All this means is a "guarantee" that +RW media is properly recognised, > nothing more. > MMC says: > "This feature may be present only to represent additional capability to > the > DVD-ROM Profile. If the Write bit is > set to zero, then no additional capability is claimed." > > I understand "then no additional capability is claimed." as compared to > the > DVD-ROM profile. > The DVD-ROM profile's "interesting" feature is the DVD Read feature. > The DVD read feature does not include the "READ DISC INFORMATION" command. > > In other words, a ROM drive that supports the DVD+ profiles and features, > but doesn't support the write bit to one, does no more than a DVD-ROM > drive > without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee > that DVD+R/W is supported *EVEN* when the booktype is still the original > booktype, and not the DVD-ROM booktype that is often used for > compatibility. > > I could be wrong, but this is how I understand it. > > PS., also from MMC (for the DVD+R feature for instance) > "If a Drive reports this feature with the Write bit set to one and the > Current bit set to one, then it shall support the > commands shown in table ..... " > > So only when the write bit is set to one additonal commands are supported, > including: > the "READ DISC INFORMATION" command > > > Best Regards, > Peter > ------------------------------------------------------- > Peter Van Hove > www.Smart-Projects.net > www.IsoBuster.com > ------------------------------------------------------- > ------------------------------------------------------- > ----- Original Message ----- > From: "David Burg" > To: > Cc: ; "Bhanu Gogineni" ; "Ahmed > Tolba" > Sent: Monday, October 16, 2006 8:10 PM > Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > >>* From the T10 Reflector (t10 at t10.org), posted by: >> * David Burg >> * >> Hello Katata-san, >> >> Thank you for your answer. Your analysis is correct, in particular for CD >> and DVD dash where the said profile requests write features to be >> supported. But remains the particularity of the DVD plus command set, >> where the profile does not request write features to be supported unless >> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >> always mandatory, and this one includes the same READ DISC INFORMATION >> you >> mention. >> >> Best regards, >> >> David Burg. >> >> -----Original Message----- >> From: owner-mtfuji5 at avc-pioneer.com >> [mailto:owner-mtfuji5 at avc-pioneer.com] >> On Behalf Of keiji_katata at post.pioneer.co.jp >> Sent: Sunday, October 15, 2006 11:47 PM >> To: mtfuji5 at avc-pioneer.com >> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >> profiles >> >> >> Hi David, >> >> ----- Question ----- >> So the question is: Does reporting R and/or RW/Rewritable profile by a >> drive >> mandate that it is capable of recognizing the matching blank R and/or >> RW/Rewritable profile? >> ------------------- >> I think it is yes. All commands listed in the Features those are listed >> in >> the >> Profile shall work correctly. So for example, CD-R profile requests >> "Incremental >> Streaming Writable Feature" and "CD Track at Once Feature". These >> Features >> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >> Those >> information must be reported from any condition of the CD-R disc except >> fatal >> error condition of the drive. I think Blank condition of CD-R is normal >> condition of the disc. >> >> On the other hand, these Feature request "This Feature identifies a Drive >> that >> is able to write data". Therefore ROM drive shall not report the >> supporting of >> there Features. Then ROM drive cannot report CD-R profile. >> >> Best regards, >> >> Keiji Katata >> PIONEER CORP. >> >> >> >> >> >> David Burg @avc-pioneer.com on 2006/10/14 >> 14:05:28 >> >> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B >> >> $BAw?.> >> >> >> >> $B08 at h(B: , >> cc: Bhanu Gogineni , Ahmed Tolba >> >> bcc: >> $B7oL>(B: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Hello, >> >> During validation of DVD-ROM devices conformance to the MMC command set >> through >> the Windows Vista Logo program and MMCTest tool, we were signaled the >> possible >> flaw in either our tool or the specification. Our tool query from the >> drive the >> list of profiles supported by the drive, and then exercises each of the >> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >> tool >> attempts to validate these profiles, and as part of the validation >> attempts to >> validate that the drive recognize blank media properly. >> >> Yes, blank media. I understand that hardware manufacturers may very well >> be >> reluctant to guarantee this capability on ROM drives. The value of >> recognizing >> blank media in a ROM drive that won$B!G(Bt be able to write it is also >> questionable. >> However there are also positives aspects: a ROM drive able to recognize >> the >> blank media will not spin un-definitively in attempt to find a track, it >> will >> further be capable to report that the media is blank to the host so that >> the >> host software may report the issue to the user and help him to correct >> his >> mistake. >> >> Clearly some ROM drives do not support recognizing blank recordable or >> rewritable media, even sometimes do not recognize recorded recordable or >> rewritable media. >> >> So the question is: Does reporting R and/or RW/Rewritable profile by a >> drive >> mandate that it is capable of recognizing the matching blank R and/or >> RW/Rewritable profile? >> >> Best regards, >> >> David Burg, >> Microsoft Corporation. >> >> >> >> >> >> >> >> >> >> >> * >> * For T10 Reflector information, send a message with >> * 'info t10' (no quotes) in the message body to majordomo at t10.org >> > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From daviburg at windows.microsoft.com Tue Oct 17 14:58:18 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Tue, 17 Oct 2006 14:58:18 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Dear Peter, All, I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." Best regards, David Burg, Microsoft. -----Original Message----- From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove Sent: Tuesday, October 17, 2006 2:19 PM To: mtfuji5 at avc-pioneer.com; t10 at t10.org Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Dear David, All, > If I correctly understand your analysis, you analyzed the capabilities > claim from the DVD+R/W *feature(s)*. I mentioned both, as both can only live together. If the plus profile is reported the plus features will be present as well. > "A device may report this feature only when Profile 10h (DVD-ROM) is > reported" Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. I interpret that as, a drive must be a DVD ROM capable drive to be able to do DVD+R/W. > And in the profile definition, the additional commands support is listed > as mandatory. ("Drives identifying Profile 001Ah as current shall support > the features listed in Table 221.") I'm not using the same rev as you do, as it's table 220 in my spec :) But I'm not sure what you mean ? All it says is what features should be supported. And the features that are write related have a small uppercase 1 next to them, indicating: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." So the presence of the plus R/W profiles does not guarantee the availability of features that deal with writing, only those that deal with reading. And hence no guarantee that commands such as "Read Disc Information" are supported, which you need to be able to recognize blank media. > Would it be correct then to say that a DVD-ROM that want to claim only > recognition of DVD+R/RW but *not* of additional commands has to list only > the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the > DVD+R/RW profile(s)? I think that a DVD-ROM drive that either does or doesn't support the +R/W profiles (and features) doesn't need to support the special commands that you need to determine blank media. > I still don't know actually if this would mean that blank DVD+R/RW media > are recognized or not. Bet on the fact that 99% of the ROM drives won't see blank media. And the availability of plus R/RW features and profiles is no indication nor guarantee that the drive can recognise blank media. > would it be correct to claim that devices claiming DVD+R/RW support have > to support blank DVD+R/RW also? No, only if they set the write bit to one. Best Regards, Peter ------------------------------------------------------- Peter Van Hove, CEO Smart Projects CD and DVD Data recovery Peter at Smart-Projects.net www.Smart-Projects.net www.IsoBuster.com ------------------------------------------------------- ----- Original Message ----- From: "David Burg" To: "Peter Van Hove" ; ; Sent: Tuesday, October 17, 2006 10:30 PM Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > Dear Peter, All, > > If I correctly understand your analysis, you analyzed the capabilities > claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted > for "This feature may be present only to represent additional capability > to the > DVD-ROM Profile. If the Write bit is set to zero, then no additional > capability is claimed.", is also said eventually "A device may report this > feature only when Profile 10h (DVD-ROM) is reported. No additional > commands or mode parameters are required." > > I am working on drives that reports the DVD+R/RW *profile*, not only the > feature. And in the profile definition, the additional commands support is > listed as mandatory. ("Drives identifying Profile 001Ah as current shall > support the features listed in Table 221.") > > Would it be correct then to say that a DVD-ROM that want to claim only > recognition of DVD+R/RW but *not* of additional commands has to list only > the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the > DVD+R/RW profile(s)? > > I still don't know actually if this would mean that blank DVD+R/RW media > are recognized or not. As the MMC specification does not make a > distinction in the support of DVD+R/RW between blank and recorded media, > would it be correct to claim that devices claiming DVD+R/RW support have > to support blank DVD+R/RW also? > > Best regards, > > David Burg, > Microsoft. > > -----Original Message----- > From: Peter Van Hove [mailto:Peter at Smart-Projects.net] > Sent: Monday, October 16, 2006 1:26 PM > To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Dear David, All, > > I hope I'm not completely missing the point but > for DVD+R/W the way I understand it is the following. > > Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles > (and > hence also no features), then a modern drive will likely have no issues > with > DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs > and > blank media will likely not be seen as such. > > Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a > host must still request the relevant features to see if that drive is able > to write also in addition to reading the media. Since the ROM drive can't > write, the write bit will be set to zero. > All this means is a "guarantee" that +RW media is properly recognised, > nothing more. > MMC says: > "This feature may be present only to represent additional capability to > the > DVD-ROM Profile. If the Write bit is > set to zero, then no additional capability is claimed." > > I understand "then no additional capability is claimed." as compared to > the > DVD-ROM profile. > The DVD-ROM profile's "interesting" feature is the DVD Read feature. > The DVD read feature does not include the "READ DISC INFORMATION" command. > > In other words, a ROM drive that supports the DVD+ profiles and features, > but doesn't support the write bit to one, does no more than a DVD-ROM > drive > without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee > that DVD+R/W is supported *EVEN* when the booktype is still the original > booktype, and not the DVD-ROM booktype that is often used for > compatibility. > > I could be wrong, but this is how I understand it. > > PS., also from MMC (for the DVD+R feature for instance) > "If a Drive reports this feature with the Write bit set to one and the > Current bit set to one, then it shall support the > commands shown in table ..... " > > So only when the write bit is set to one additonal commands are supported, > including: > the "READ DISC INFORMATION" command > > > Best Regards, > Peter > ------------------------------------------------------- > Peter Van Hove > www.Smart-Projects.net > www.IsoBuster.com > ------------------------------------------------------- > ------------------------------------------------------- > ----- Original Message ----- > From: "David Burg" > To: > Cc: ; "Bhanu Gogineni" ; "Ahmed > Tolba" > Sent: Monday, October 16, 2006 8:10 PM > Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > >>* From the T10 Reflector (t10 at t10.org), posted by: >> * David Burg >> * >> Hello Katata-san, >> >> Thank you for your answer. Your analysis is correct, in particular for CD >> and DVD dash where the said profile requests write features to be >> supported. But remains the particularity of the DVD plus command set, >> where the profile does not request write features to be supported unless >> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >> always mandatory, and this one includes the same READ DISC INFORMATION >> you >> mention. >> >> Best regards, >> >> David Burg. >> >> -----Original Message----- >> From: owner-mtfuji5 at avc-pioneer.com >> [mailto:owner-mtfuji5 at avc-pioneer.com] >> On Behalf Of keiji_katata at post.pioneer.co.jp >> Sent: Sunday, October 15, 2006 11:47 PM >> To: mtfuji5 at avc-pioneer.com >> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >> profiles >> >> >> Hi David, >> >> ----- Question ----- >> So the question is: Does reporting R and/or RW/Rewritable profile by a >> drive >> mandate that it is capable of recognizing the matching blank R and/or >> RW/Rewritable profile? >> ------------------- >> I think it is yes. All commands listed in the Features those are listed >> in >> the >> Profile shall work correctly. So for example, CD-R profile requests >> "Incremental >> Streaming Writable Feature" and "CD Track at Once Feature". These >> Features >> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >> Those >> information must be reported from any condition of the CD-R disc except >> fatal >> error condition of the drive. I think Blank condition of CD-R is normal >> condition of the disc. >> >> On the other hand, these Feature request "This Feature identifies a Drive >> that >> is able to write data". Therefore ROM drive shall not report the >> supporting of >> there Features. Then ROM drive cannot report CD-R profile. >> >> Best regards, >> >> Keiji Katata >> PIONEER CORP. >> >> >> >> >> >> David Burg @avc-pioneer.com on 2006/10/14 >> 14:05:28 >> >> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J >> >> $BAw?.> >> >> >> >> $B08 at h(J: , >> cc: Bhanu Gogineni , Ahmed Tolba >> >> bcc: >> $B7oL>(J: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Hello, >> >> During validation of DVD-ROM devices conformance to the MMC command set >> through >> the Windows Vista Logo program and MMCTest tool, we were signaled the >> possible >> flaw in either our tool or the specification. Our tool query from the >> drive the >> list of profiles supported by the drive, and then exercises each of the >> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >> tool >> attempts to validate these profiles, and as part of the validation >> attempts to >> validate that the drive recognize blank media properly. >> >> Yes, blank media. I understand that hardware manufacturers may very well >> be >> reluctant to guarantee this capability on ROM drives. The value of >> recognizing >> blank media in a ROM drive that won$B!G(Jt be able to write it is also >> questionable. >> However there are also positives aspects: a ROM drive able to recognize >> the >> blank media will not spin un-definitively in attempt to find a track, it >> will >> further be capable to report that the media is blank to the host so that >> the >> host software may report the issue to the user and help him to correct >> his >> mistake. >> >> Clearly some ROM drives do not support recognizing blank recordable or >> rewritable media, even sometimes do not recognize recorded recordable or >> rewritable media. >> >> So the question is: Does reporting R and/or RW/Rewritable profile by a >> drive >> mandate that it is capable of recognizing the matching blank R and/or >> RW/Rewritable profile? >> >> Best regards, >> >> David Burg, >> Microsoft Corporation. >> >> >> >> >> >> >> >> >> >> >> * >> * For T10 Reflector information, send a message with >> * 'info t10' (no quotes) in the message body to majordomo at t10.org >> > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From billmc37 at ctesc.net Wed Oct 18 16:16:19 2006 From: billmc37 at ctesc.net (Bill McFerrin) Date: Wed, 18 Oct 2006 18:16:19 -0500 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Bill McFerrin * Hi David, There is less to this than you think. In the beginning (sort of), there was DVD-ROM and no writables. Some DVD-ROM drives rejected recorded DVD+RW discs (and sometimes others as well). We wanted a simple way for a DVD-ROM Drive to claim the ability to read recorded DVD+ discs. Each DVD+ feature followed that idea for consistency. Each DVD+ profile requires the ability to record. That's it. Kind Regards, Bill McFerrin David Burg wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Dear Peter, All, > > I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org > > Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." > > Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: > > "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." > > Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." > > Best regards, > > David Burg, > Microsoft. > > -----Original Message----- > From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove > Sent: Tuesday, October 17, 2006 2:19 PM > To: mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Dear David, All, > > >> If I correctly understand your analysis, you analyzed the capabilities >> claim from the DVD+R/W *feature(s)*. >> > > I mentioned both, as both can only live together. If the plus profile is > reported the plus features will be present as well. > > >> "A device may report this feature only when Profile 10h (DVD-ROM) is >> reported" >> > > Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. > I interpret that as, a drive must be a DVD ROM capable drive to be able to > do DVD+R/W. > > >> And in the profile definition, the additional commands support is listed >> as mandatory. ("Drives identifying Profile 001Ah as current shall support >> the features listed in Table 221.") >> > > I'm not using the same rev as you do, as it's table 220 in my spec :) > But I'm not sure what you mean ? > All it says is what features should be supported. > And the features that are write related have a small uppercase 1 next to > them, indicating: > "1 This feature is mandatory only when the Write bit of the DVD+RW Feature > is set to one." > > So the presence of the plus R/W profiles does not guarantee the availability > of features that deal with writing, only those that deal with reading. > And hence no guarantee that commands such as "Read Disc Information" are > supported, which you need to be able to recognize blank media. > > >> Would it be correct then to say that a DVD-ROM that want to claim only >> recognition of DVD+R/RW but *not* of additional commands has to list only >> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >> DVD+R/RW profile(s)? >> > > I think that a DVD-ROM drive that either does or doesn't support the +R/W > profiles (and features) doesn't need to support the special commands that > you need to determine blank media. > > >> I still don't know actually if this would mean that blank DVD+R/RW media >> are recognized or not. >> > > Bet on the fact that 99% of the ROM drives won't see blank media. > And the availability of plus R/RW features and profiles is no indication nor > guarantee that the drive can recognise blank media. > > >> would it be correct to claim that devices claiming DVD+R/RW support have >> to support blank DVD+R/RW also? >> > > No, only if they set the write bit to one. > > Best Regards, > Peter > ------------------------------------------------------- > Peter Van Hove, CEO Smart Projects > CD and DVD Data recovery > Peter at Smart-Projects.net > > www.Smart-Projects.net > www.IsoBuster.com > ------------------------------------------------------- > ----- Original Message ----- > From: "David Burg" > To: "Peter Van Hove" ; ; > > Sent: Tuesday, October 17, 2006 10:30 PM > Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > > >> Dear Peter, All, >> >> If I correctly understand your analysis, you analyzed the capabilities >> claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted >> for "This feature may be present only to represent additional capability >> to the >> DVD-ROM Profile. If the Write bit is set to zero, then no additional >> capability is claimed.", is also said eventually "A device may report this >> feature only when Profile 10h (DVD-ROM) is reported. No additional >> commands or mode parameters are required." >> >> I am working on drives that reports the DVD+R/RW *profile*, not only the >> feature. And in the profile definition, the additional commands support is >> listed as mandatory. ("Drives identifying Profile 001Ah as current shall >> support the features listed in Table 221.") >> >> Would it be correct then to say that a DVD-ROM that want to claim only >> recognition of DVD+R/RW but *not* of additional commands has to list only >> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >> DVD+R/RW profile(s)? >> >> I still don't know actually if this would mean that blank DVD+R/RW media >> are recognized or not. As the MMC specification does not make a >> distinction in the support of DVD+R/RW between blank and recorded media, >> would it be correct to claim that devices claiming DVD+R/RW support have >> to support blank DVD+R/RW also? >> >> Best regards, >> >> David Burg, >> Microsoft. >> >> -----Original Message----- >> From: Peter Van Hove [mailto:Peter at Smart-Projects.net] >> Sent: Monday, October 16, 2006 1:26 PM >> To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Dear David, All, >> >> I hope I'm not completely missing the point but >> for DVD+R/W the way I understand it is the following. >> >> Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles >> (and >> hence also no features), then a modern drive will likely have no issues >> with >> DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs >> and >> blank media will likely not be seen as such. >> >> Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a >> host must still request the relevant features to see if that drive is able >> to write also in addition to reading the media. Since the ROM drive can't >> write, the write bit will be set to zero. >> All this means is a "guarantee" that +RW media is properly recognised, >> nothing more. >> MMC says: >> "This feature may be present only to represent additional capability to >> the >> DVD-ROM Profile. If the Write bit is >> set to zero, then no additional capability is claimed." >> >> I understand "then no additional capability is claimed." as compared to >> the >> DVD-ROM profile. >> The DVD-ROM profile's "interesting" feature is the DVD Read feature. >> The DVD read feature does not include the "READ DISC INFORMATION" command. >> >> In other words, a ROM drive that supports the DVD+ profiles and features, >> but doesn't support the write bit to one, does no more than a DVD-ROM >> drive >> without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee >> that DVD+R/W is supported *EVEN* when the booktype is still the original >> booktype, and not the DVD-ROM booktype that is often used for >> compatibility. >> >> I could be wrong, but this is how I understand it. >> >> PS., also from MMC (for the DVD+R feature for instance) >> "If a Drive reports this feature with the Write bit set to one and the >> Current bit set to one, then it shall support the >> commands shown in table ..... " >> >> So only when the write bit is set to one additonal commands are supported, >> including: >> the "READ DISC INFORMATION" command >> >> >> Best Regards, >> Peter >> ------------------------------------------------------- >> Peter Van Hove >> www.Smart-Projects.net >> www.IsoBuster.com >> ------------------------------------------------------- >> ------------------------------------------------------- >> ----- Original Message ----- >> From: "David Burg" >> To: >> Cc: ; "Bhanu Gogineni" ; "Ahmed >> Tolba" >> Sent: Monday, October 16, 2006 8:10 PM >> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> >> >>> * From the T10 Reflector (t10 at t10.org), posted by: >>> * David Burg >>> * >>> Hello Katata-san, >>> >>> Thank you for your answer. Your analysis is correct, in particular for CD >>> and DVD dash where the said profile requests write features to be >>> supported. But remains the particularity of the DVD plus command set, >>> where the profile does not request write features to be supported unless >>> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >>> always mandatory, and this one includes the same READ DISC INFORMATION >>> you >>> mention. >>> >>> Best regards, >>> >>> David Burg. >>> >>> -----Original Message----- >>> From: owner-mtfuji5 at avc-pioneer.com >>> [mailto:owner-mtfuji5 at avc-pioneer.com] >>> On Behalf Of keiji_katata at post.pioneer.co.jp >>> Sent: Sunday, October 15, 2006 11:47 PM >>> To: mtfuji5 at avc-pioneer.com >>> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >>> profiles >>> >>> >>> Hi David, >>> >>> ----- Question ----- >>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>> drive >>> mandate that it is capable of recognizing the matching blank R and/or >>> RW/Rewritable profile? >>> ------------------- >>> I think it is yes. All commands listed in the Features those are listed >>> in >>> the >>> Profile shall work correctly. So for example, CD-R profile requests >>> "Incremental >>> Streaming Writable Feature" and "CD Track at Once Feature". These >>> Features >>> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >>> Those >>> information must be reported from any condition of the CD-R disc except >>> fatal >>> error condition of the drive. I think Blank condition of CD-R is normal >>> condition of the disc. >>> >>> On the other hand, these Feature request "This Feature identifies a Drive >>> that >>> is able to write data". Therefore ROM drive shall not report the >>> supporting of >>> there Features. Then ROM drive cannot report CD-R profile. >>> >>> Best regards, >>> >>> Keiji Katata >>> PIONEER CORP. >>> >>> >>> >>> >>> >>> David Burg @avc-pioneer.com on 2006/10/14 >>> 14:05:28 >>> >>> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B >>> >>> $BAw?.>> >>> >>> >>> >>> $B08 at h(B: , >>> cc: Bhanu Gogineni , Ahmed Tolba >>> >>> bcc: >>> $B7oL>(B: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> Hello, >>> >>> During validation of DVD-ROM devices conformance to the MMC command set >>> through >>> the Windows Vista Logo program and MMCTest tool, we were signaled the >>> possible >>> flaw in either our tool or the specification. Our tool query from the >>> drive the >>> list of profiles supported by the drive, and then exercises each of the >>> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >>> tool >>> attempts to validate these profiles, and as part of the validation >>> attempts to >>> validate that the drive recognize blank media properly. >>> >>> Yes, blank media. I understand that hardware manufacturers may very well >>> be >>> reluctant to guarantee this capability on ROM drives. The value of >>> recognizing >>> blank media in a ROM drive that won$B!G(Bt be able to write it is also >>> questionable. >>> However there are also positives aspects: a ROM drive able to recognize >>> the >>> blank media will not spin un-definitively in attempt to find a track, it >>> will >>> further be capable to report that the media is blank to the host so that >>> the >>> host software may report the issue to the user and help him to correct >>> his >>> mistake. >>> >>> Clearly some ROM drives do not support recognizing blank recordable or >>> rewritable media, even sometimes do not recognize recorded recordable or >>> rewritable media. >>> >>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>> drive >>> mandate that it is capable of recognizing the matching blank R and/or >>> RW/Rewritable profile? >>> >>> Best regards, >>> >>> David Burg, >>> Microsoft Corporation. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> * >>> * For T10 Reflector information, send a message with >>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>> >>> >> >> > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From daviburg at windows.microsoft.com Wed Oct 18 17:43:34 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Wed, 18 Oct 2006 17:43:34 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Hi Bill, You said: "Each DVD+ profile requires the ability to record." But the spec says in a note for the write features of the + profiles: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." Does DVD+ profile really require the ability to record? Best regards, David Burg. -----Original Message----- From: Bill McFerrin [mailto:billmc37 at ctesc.net] Sent: Wednesday, October 18, 2006 4:16 PM To: David Burg Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Hi David, There is less to this than you think. In the beginning (sort of), there was DVD-ROM and no writables. Some DVD-ROM drives rejected recorded DVD+RW discs (and sometimes others as well). We wanted a simple way for a DVD-ROM Drive to claim the ability to read recorded DVD+ discs. Each DVD+ feature followed that idea for consistency. Each DVD+ profile requires the ability to record. That's it. Kind Regards, Bill McFerrin David Burg wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Dear Peter, All, > > I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org > > Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." > > Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: > > "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." > > Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." > > Best regards, > > David Burg, > Microsoft. > > -----Original Message----- > From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove > Sent: Tuesday, October 17, 2006 2:19 PM > To: mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Dear David, All, > > >> If I correctly understand your analysis, you analyzed the capabilities >> claim from the DVD+R/W *feature(s)*. >> > > I mentioned both, as both can only live together. If the plus profile is > reported the plus features will be present as well. > > >> "A device may report this feature only when Profile 10h (DVD-ROM) is >> reported" >> > > Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. > I interpret that as, a drive must be a DVD ROM capable drive to be able to > do DVD+R/W. > > >> And in the profile definition, the additional commands support is listed >> as mandatory. ("Drives identifying Profile 001Ah as current shall support >> the features listed in Table 221.") >> > > I'm not using the same rev as you do, as it's table 220 in my spec :) > But I'm not sure what you mean ? > All it says is what features should be supported. > And the features that are write related have a small uppercase 1 next to > them, indicating: > "1 This feature is mandatory only when the Write bit of the DVD+RW Feature > is set to one." > > So the presence of the plus R/W profiles does not guarantee the availability > of features that deal with writing, only those that deal with reading. > And hence no guarantee that commands such as "Read Disc Information" are > supported, which you need to be able to recognize blank media. > > >> Would it be correct then to say that a DVD-ROM that want to claim only >> recognition of DVD+R/RW but *not* of additional commands has to list only >> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >> DVD+R/RW profile(s)? >> > > I think that a DVD-ROM drive that either does or doesn't support the +R/W > profiles (and features) doesn't need to support the special commands that > you need to determine blank media. > > >> I still don't know actually if this would mean that blank DVD+R/RW media >> are recognized or not. >> > > Bet on the fact that 99% of the ROM drives won't see blank media. > And the availability of plus R/RW features and profiles is no indication nor > guarantee that the drive can recognise blank media. > > >> would it be correct to claim that devices claiming DVD+R/RW support have >> to support blank DVD+R/RW also? >> > > No, only if they set the write bit to one. > > Best Regards, > Peter > ------------------------------------------------------- > Peter Van Hove, CEO Smart Projects > CD and DVD Data recovery > Peter at Smart-Projects.net > > www.Smart-Projects.net > www.IsoBuster.com > ------------------------------------------------------- > ----- Original Message ----- > From: "David Burg" > To: "Peter Van Hove" ; ; > > Sent: Tuesday, October 17, 2006 10:30 PM > Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > > >> Dear Peter, All, >> >> If I correctly understand your analysis, you analyzed the capabilities >> claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted >> for "This feature may be present only to represent additional capability >> to the >> DVD-ROM Profile. If the Write bit is set to zero, then no additional >> capability is claimed.", is also said eventually "A device may report this >> feature only when Profile 10h (DVD-ROM) is reported. No additional >> commands or mode parameters are required." >> >> I am working on drives that reports the DVD+R/RW *profile*, not only the >> feature. And in the profile definition, the additional commands support is >> listed as mandatory. ("Drives identifying Profile 001Ah as current shall >> support the features listed in Table 221.") >> >> Would it be correct then to say that a DVD-ROM that want to claim only >> recognition of DVD+R/RW but *not* of additional commands has to list only >> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >> DVD+R/RW profile(s)? >> >> I still don't know actually if this would mean that blank DVD+R/RW media >> are recognized or not. As the MMC specification does not make a >> distinction in the support of DVD+R/RW between blank and recorded media, >> would it be correct to claim that devices claiming DVD+R/RW support have >> to support blank DVD+R/RW also? >> >> Best regards, >> >> David Burg, >> Microsoft. >> >> -----Original Message----- >> From: Peter Van Hove [mailto:Peter at Smart-Projects.net] >> Sent: Monday, October 16, 2006 1:26 PM >> To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Dear David, All, >> >> I hope I'm not completely missing the point but >> for DVD+R/W the way I understand it is the following. >> >> Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles >> (and >> hence also no features), then a modern drive will likely have no issues >> with >> DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs >> and >> blank media will likely not be seen as such. >> >> Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a >> host must still request the relevant features to see if that drive is able >> to write also in addition to reading the media. Since the ROM drive can't >> write, the write bit will be set to zero. >> All this means is a "guarantee" that +RW media is properly recognised, >> nothing more. >> MMC says: >> "This feature may be present only to represent additional capability to >> the >> DVD-ROM Profile. If the Write bit is >> set to zero, then no additional capability is claimed." >> >> I understand "then no additional capability is claimed." as compared to >> the >> DVD-ROM profile. >> The DVD-ROM profile's "interesting" feature is the DVD Read feature. >> The DVD read feature does not include the "READ DISC INFORMATION" command. >> >> In other words, a ROM drive that supports the DVD+ profiles and features, >> but doesn't support the write bit to one, does no more than a DVD-ROM >> drive >> without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee >> that DVD+R/W is supported *EVEN* when the booktype is still the original >> booktype, and not the DVD-ROM booktype that is often used for >> compatibility. >> >> I could be wrong, but this is how I understand it. >> >> PS., also from MMC (for the DVD+R feature for instance) >> "If a Drive reports this feature with the Write bit set to one and the >> Current bit set to one, then it shall support the >> commands shown in table ..... " >> >> So only when the write bit is set to one additonal commands are supported, >> including: >> the "READ DISC INFORMATION" command >> >> >> Best Regards, >> Peter >> ------------------------------------------------------- >> Peter Van Hove >> www.Smart-Projects.net >> www.IsoBuster.com >> ------------------------------------------------------- >> ------------------------------------------------------- >> ----- Original Message ----- >> From: "David Burg" >> To: >> Cc: ; "Bhanu Gogineni" ; "Ahmed >> Tolba" >> Sent: Monday, October 16, 2006 8:10 PM >> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> >> >>> * From the T10 Reflector (t10 at t10.org), posted by: >>> * David Burg >>> * >>> Hello Katata-san, >>> >>> Thank you for your answer. Your analysis is correct, in particular for CD >>> and DVD dash where the said profile requests write features to be >>> supported. But remains the particularity of the DVD plus command set, >>> where the profile does not request write features to be supported unless >>> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >>> always mandatory, and this one includes the same READ DISC INFORMATION >>> you >>> mention. >>> >>> Best regards, >>> >>> David Burg. >>> >>> -----Original Message----- >>> From: owner-mtfuji5 at avc-pioneer.com >>> [mailto:owner-mtfuji5 at avc-pioneer.com] >>> On Behalf Of keiji_katata at post.pioneer.co.jp >>> Sent: Sunday, October 15, 2006 11:47 PM >>> To: mtfuji5 at avc-pioneer.com >>> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >>> profiles >>> >>> >>> Hi David, >>> >>> ----- Question ----- >>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>> drive >>> mandate that it is capable of recognizing the matching blank R and/or >>> RW/Rewritable profile? >>> ------------------- >>> I think it is yes. All commands listed in the Features those are listed >>> in >>> the >>> Profile shall work correctly. So for example, CD-R profile requests >>> "Incremental >>> Streaming Writable Feature" and "CD Track at Once Feature". These >>> Features >>> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >>> Those >>> information must be reported from any condition of the CD-R disc except >>> fatal >>> error condition of the drive. I think Blank condition of CD-R is normal >>> condition of the disc. >>> >>> On the other hand, these Feature request "This Feature identifies a Drive >>> that >>> is able to write data". Therefore ROM drive shall not report the >>> supporting of >>> there Features. Then ROM drive cannot report CD-R profile. >>> >>> Best regards, >>> >>> Keiji Katata >>> PIONEER CORP. >>> >>> >>> >>> >>> >>> David Burg @avc-pioneer.com on 2006/10/14 >>> 14:05:28 >>> >>> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J >>> >>> $BAw?.>> >>> >>> >>> >>> $B08 at h(J: , >>> cc: Bhanu Gogineni , Ahmed Tolba >>> >>> bcc: >>> $B7oL>(J: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> Hello, >>> >>> During validation of DVD-ROM devices conformance to the MMC command set >>> through >>> the Windows Vista Logo program and MMCTest tool, we were signaled the >>> possible >>> flaw in either our tool or the specification. Our tool query from the >>> drive the >>> list of profiles supported by the drive, and then exercises each of the >>> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >>> tool >>> attempts to validate these profiles, and as part of the validation >>> attempts to >>> validate that the drive recognize blank media properly. >>> >>> Yes, blank media. I understand that hardware manufacturers may very well >>> be >>> reluctant to guarantee this capability on ROM drives. The value of >>> recognizing >>> blank media in a ROM drive that won$B!G(Jt be able to write it is also >>> questionable. >>> However there are also positives aspects: a ROM drive able to recognize >>> the >>> blank media will not spin un-definitively in attempt to find a track, it >>> will >>> further be capable to report that the media is blank to the host so that >>> the >>> host software may report the issue to the user and help him to correct >>> his >>> mistake. >>> >>> Clearly some ROM drives do not support recognizing blank recordable or >>> rewritable media, even sometimes do not recognize recorded recordable or >>> rewritable media. >>> >>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>> drive >>> mandate that it is capable of recognizing the matching blank R and/or >>> RW/Rewritable profile? >>> >>> Best regards, >>> >>> David Burg, >>> Microsoft Corporation. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> * >>> * For T10 Reflector information, send a message with >>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>> >>> >> >> > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From billmc37 at ctesc.net Thu Oct 19 07:05:07 2006 From: billmc37 at ctesc.net (Bill McFerrin) Date: Thu, 19 Oct 2006 09:05:07 -0500 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Bill McFerrin * Ouch, It gets worse. The paragraph below the DVD+RW Profile states that the Write bit must be set to one. I will be posting rev 4 this weekend with fixes based upon the ANSI editor's comments. The clarification here is to remove the footnotes that cause confusion. Kind Regards, Bill David Burg wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Hi Bill, > > You said: "Each DVD+ profile requires the ability to record." > > But the spec says in a note for the write features of the + profiles: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." > > Does DVD+ profile really require the ability to record? > > Best regards, > > David Burg. > > -----Original Message----- > From: Bill McFerrin [mailto:billmc37 at ctesc.net] > Sent: Wednesday, October 18, 2006 4:16 PM > To: David Burg > Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Hi David, > There is less to this than you think. > > In the beginning (sort of), there was DVD-ROM and no writables. Some > DVD-ROM drives rejected recorded DVD+RW discs (and sometimes others as > well). We wanted a simple way for a DVD-ROM Drive to claim the ability > to read recorded DVD+ discs. Each DVD+ feature followed that idea for > consistency. > > Each DVD+ profile requires the ability to record. > > That's it. > > Kind Regards, > Bill McFerrin > > David Burg wrote: > >> * From the T10 Reflector (t10 at t10.org), posted by: >> * David Burg >> * >> Dear Peter, All, >> >> I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org >> >> Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." >> >> Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: >> >> "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." >> >> Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." >> >> Best regards, >> >> David Burg, >> Microsoft. >> >> -----Original Message----- >> From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove >> Sent: Tuesday, October 17, 2006 2:19 PM >> To: mtfuji5 at avc-pioneer.com; t10 at t10.org >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Dear David, All, >> >> >> >>> If I correctly understand your analysis, you analyzed the capabilities >>> claim from the DVD+R/W *feature(s)*. >>> >>> >> I mentioned both, as both can only live together. If the plus profile is >> reported the plus features will be present as well. >> >> >> >>> "A device may report this feature only when Profile 10h (DVD-ROM) is >>> reported" >>> >>> >> Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. >> I interpret that as, a drive must be a DVD ROM capable drive to be able to >> do DVD+R/W. >> >> >> >>> And in the profile definition, the additional commands support is listed >>> as mandatory. ("Drives identifying Profile 001Ah as current shall support >>> the features listed in Table 221.") >>> >>> >> I'm not using the same rev as you do, as it's table 220 in my spec :) >> But I'm not sure what you mean ? >> All it says is what features should be supported. >> And the features that are write related have a small uppercase 1 next to >> them, indicating: >> "1 This feature is mandatory only when the Write bit of the DVD+RW Feature >> is set to one." >> >> So the presence of the plus R/W profiles does not guarantee the availability >> of features that deal with writing, only those that deal with reading. >> And hence no guarantee that commands such as "Read Disc Information" are >> supported, which you need to be able to recognize blank media. >> >> >> >>> Would it be correct then to say that a DVD-ROM that want to claim only >>> recognition of DVD+R/RW but *not* of additional commands has to list only >>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>> DVD+R/RW profile(s)? >>> >>> >> I think that a DVD-ROM drive that either does or doesn't support the +R/W >> profiles (and features) doesn't need to support the special commands that >> you need to determine blank media. >> >> >> >>> I still don't know actually if this would mean that blank DVD+R/RW media >>> are recognized or not. >>> >>> >> Bet on the fact that 99% of the ROM drives won't see blank media. >> And the availability of plus R/RW features and profiles is no indication nor >> guarantee that the drive can recognise blank media. >> >> >> >>> would it be correct to claim that devices claiming DVD+R/RW support have >>> to support blank DVD+R/RW also? >>> >>> >> No, only if they set the write bit to one. >> >> Best Regards, >> Peter >> ------------------------------------------------------- >> Peter Van Hove, CEO Smart Projects >> CD and DVD Data recovery >> Peter at Smart-Projects.net >> >> www.Smart-Projects.net >> www.IsoBuster.com >> ------------------------------------------------------- >> ----- Original Message ----- >> From: "David Burg" >> To: "Peter Van Hove" ; ; >> >> Sent: Tuesday, October 17, 2006 10:30 PM >> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> >> >> >>> Dear Peter, All, >>> >>> If I correctly understand your analysis, you analyzed the capabilities >>> claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted >>> for "This feature may be present only to represent additional capability >>> to the >>> DVD-ROM Profile. If the Write bit is set to zero, then no additional >>> capability is claimed.", is also said eventually "A device may report this >>> feature only when Profile 10h (DVD-ROM) is reported. No additional >>> commands or mode parameters are required." >>> >>> I am working on drives that reports the DVD+R/RW *profile*, not only the >>> feature. And in the profile definition, the additional commands support is >>> listed as mandatory. ("Drives identifying Profile 001Ah as current shall >>> support the features listed in Table 221.") >>> >>> Would it be correct then to say that a DVD-ROM that want to claim only >>> recognition of DVD+R/RW but *not* of additional commands has to list only >>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>> DVD+R/RW profile(s)? >>> >>> I still don't know actually if this would mean that blank DVD+R/RW media >>> are recognized or not. As the MMC specification does not make a >>> distinction in the support of DVD+R/RW between blank and recorded media, >>> would it be correct to claim that devices claiming DVD+R/RW support have >>> to support blank DVD+R/RW also? >>> >>> Best regards, >>> >>> David Burg, >>> Microsoft. >>> >>> -----Original Message----- >>> From: Peter Van Hove [mailto:Peter at Smart-Projects.net] >>> Sent: Monday, October 16, 2006 1:26 PM >>> To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org >>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> Dear David, All, >>> >>> I hope I'm not completely missing the point but >>> for DVD+R/W the way I understand it is the following. >>> >>> Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles >>> (and >>> hence also no features), then a modern drive will likely have no issues >>> with >>> DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs >>> and >>> blank media will likely not be seen as such. >>> >>> Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a >>> host must still request the relevant features to see if that drive is able >>> to write also in addition to reading the media. Since the ROM drive can't >>> write, the write bit will be set to zero. >>> All this means is a "guarantee" that +RW media is properly recognised, >>> nothing more. >>> MMC says: >>> "This feature may be present only to represent additional capability to >>> the >>> DVD-ROM Profile. If the Write bit is >>> set to zero, then no additional capability is claimed." >>> >>> I understand "then no additional capability is claimed." as compared to >>> the >>> DVD-ROM profile. >>> The DVD-ROM profile's "interesting" feature is the DVD Read feature. >>> The DVD read feature does not include the "READ DISC INFORMATION" command. >>> >>> In other words, a ROM drive that supports the DVD+ profiles and features, >>> but doesn't support the write bit to one, does no more than a DVD-ROM >>> drive >>> without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee >>> that DVD+R/W is supported *EVEN* when the booktype is still the original >>> booktype, and not the DVD-ROM booktype that is often used for >>> compatibility. >>> >>> I could be wrong, but this is how I understand it. >>> >>> PS., also from MMC (for the DVD+R feature for instance) >>> "If a Drive reports this feature with the Write bit set to one and the >>> Current bit set to one, then it shall support the >>> commands shown in table ..... " >>> >>> So only when the write bit is set to one additonal commands are supported, >>> including: >>> the "READ DISC INFORMATION" command >>> >>> >>> Best Regards, >>> Peter >>> ------------------------------------------------------- >>> Peter Van Hove >>> www.Smart-Projects.net >>> www.IsoBuster.com >>> ------------------------------------------------------- >>> ------------------------------------------------------- >>> ----- Original Message ----- >>> From: "David Burg" >>> To: >>> Cc: ; "Bhanu Gogineni" ; "Ahmed >>> Tolba" >>> Sent: Monday, October 16, 2006 8:10 PM >>> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> >>> >>> >>>> * From the T10 Reflector (t10 at t10.org), posted by: >>>> * David Burg >>>> * >>>> Hello Katata-san, >>>> >>>> Thank you for your answer. Your analysis is correct, in particular for CD >>>> and DVD dash where the said profile requests write features to be >>>> supported. But remains the particularity of the DVD plus command set, >>>> where the profile does not request write features to be supported unless >>>> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >>>> always mandatory, and this one includes the same READ DISC INFORMATION >>>> you >>>> mention. >>>> >>>> Best regards, >>>> >>>> David Burg. >>>> >>>> -----Original Message----- >>>> From: owner-mtfuji5 at avc-pioneer.com >>>> [mailto:owner-mtfuji5 at avc-pioneer.com] >>>> On Behalf Of keiji_katata at post.pioneer.co.jp >>>> Sent: Sunday, October 15, 2006 11:47 PM >>>> To: mtfuji5 at avc-pioneer.com >>>> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >>>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >>>> profiles >>>> >>>> >>>> Hi David, >>>> >>>> ----- Question ----- >>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>> drive >>>> mandate that it is capable of recognizing the matching blank R and/or >>>> RW/Rewritable profile? >>>> ------------------- >>>> I think it is yes. All commands listed in the Features those are listed >>>> in >>>> the >>>> Profile shall work correctly. So for example, CD-R profile requests >>>> "Incremental >>>> Streaming Writable Feature" and "CD Track at Once Feature". These >>>> Features >>>> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >>>> Those >>>> information must be reported from any condition of the CD-R disc except >>>> fatal >>>> error condition of the drive. I think Blank condition of CD-R is normal >>>> condition of the disc. >>>> >>>> On the other hand, these Feature request "This Feature identifies a Drive >>>> that >>>> is able to write data". Therefore ROM drive shall not report the >>>> supporting of >>>> there Features. Then ROM drive cannot report CD-R profile. >>>> >>>> Best regards, >>>> >>>> Keiji Katata >>>> PIONEER CORP. >>>> >>>> >>>> >>>> >>>> >>>> David Burg @avc-pioneer.com on 2006/10/14 >>>> 14:05:28 >>>> >>>> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B >>>> >>>> $BAw?.>>> >>>> >>>> >>>> >>>> $B08 at h(B: , >>>> cc: Bhanu Gogineni , Ahmed Tolba >>>> >>>> bcc: >>>> $B7oL>(B: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>> >>>> Hello, >>>> >>>> During validation of DVD-ROM devices conformance to the MMC command set >>>> through >>>> the Windows Vista Logo program and MMCTest tool, we were signaled the >>>> possible >>>> flaw in either our tool or the specification. Our tool query from the >>>> drive the >>>> list of profiles supported by the drive, and then exercises each of the >>>> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >>>> tool >>>> attempts to validate these profiles, and as part of the validation >>>> attempts to >>>> validate that the drive recognize blank media properly. >>>> >>>> Yes, blank media. I understand that hardware manufacturers may very well >>>> be >>>> reluctant to guarantee this capability on ROM drives. The value of >>>> recognizing >>>> blank media in a ROM drive that won$B!G(Bt be able to write it is also >>>> questionable. >>>> However there are also positives aspects: a ROM drive able to recognize >>>> the >>>> blank media will not spin un-definitively in attempt to find a track, it >>>> will >>>> further be capable to report that the media is blank to the host so that >>>> the >>>> host software may report the issue to the user and help him to correct >>>> his >>>> mistake. >>>> >>>> Clearly some ROM drives do not support recognizing blank recordable or >>>> rewritable media, even sometimes do not recognize recorded recordable or >>>> rewritable media. >>>> >>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>> drive >>>> mandate that it is capable of recognizing the matching blank R and/or >>>> RW/Rewritable profile? >>>> >>>> Best regards, >>>> >>>> David Burg, >>>> Microsoft Corporation. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> * >>>> * For T10 Reflector information, send a message with >>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>>> >>>> >>>> >>> >>> >> * >> * For T10 Reflector information, send a message with >> * 'info t10' (no quotes) in the message body to majordomo at t10.org >> >> >> >> > > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From daviburg at windows.microsoft.com Thu Oct 19 10:19:52 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Thu, 19 Oct 2006 10:19:52 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Ouch indeed, So you mean that a DVD-ROM drive shall never report the DVD+R/RW profiles? Because we at Microsoft have a failure in our tests precisely because of such DVD-ROM drives. Best regards, David Burg. -----Original Message----- From: Bill McFerrin [mailto:billmc37 at ctesc.net] Sent: Thursday, October 19, 2006 7:05 AM To: David Burg Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Ouch, It gets worse. The paragraph below the DVD+RW Profile states that the Write bit must be set to one. I will be posting rev 4 this weekend with fixes based upon the ANSI editor's comments. The clarification here is to remove the footnotes that cause confusion. Kind Regards, Bill David Burg wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Hi Bill, > > You said: "Each DVD+ profile requires the ability to record." > > But the spec says in a note for the write features of the + profiles: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." > > Does DVD+ profile really require the ability to record? > > Best regards, > > David Burg. > > -----Original Message----- > From: Bill McFerrin [mailto:billmc37 at ctesc.net] > Sent: Wednesday, October 18, 2006 4:16 PM > To: David Burg > Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Hi David, > There is less to this than you think. > > In the beginning (sort of), there was DVD-ROM and no writables. Some > DVD-ROM drives rejected recorded DVD+RW discs (and sometimes others as > well). We wanted a simple way for a DVD-ROM Drive to claim the ability > to read recorded DVD+ discs. Each DVD+ feature followed that idea for > consistency. > > Each DVD+ profile requires the ability to record. > > That's it. > > Kind Regards, > Bill McFerrin > > David Burg wrote: > >> * From the T10 Reflector (t10 at t10.org), posted by: >> * David Burg >> * >> Dear Peter, All, >> >> I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org >> >> Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." >> >> Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: >> >> "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." >> >> Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." >> >> Best regards, >> >> David Burg, >> Microsoft. >> >> -----Original Message----- >> From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove >> Sent: Tuesday, October 17, 2006 2:19 PM >> To: mtfuji5 at avc-pioneer.com; t10 at t10.org >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Dear David, All, >> >> >> >>> If I correctly understand your analysis, you analyzed the capabilities >>> claim from the DVD+R/W *feature(s)*. >>> >>> >> I mentioned both, as both can only live together. If the plus profile is >> reported the plus features will be present as well. >> >> >> >>> "A device may report this feature only when Profile 10h (DVD-ROM) is >>> reported" >>> >>> >> Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. >> I interpret that as, a drive must be a DVD ROM capable drive to be able to >> do DVD+R/W. >> >> >> >>> And in the profile definition, the additional commands support is listed >>> as mandatory. ("Drives identifying Profile 001Ah as current shall support >>> the features listed in Table 221.") >>> >>> >> I'm not using the same rev as you do, as it's table 220 in my spec :) >> But I'm not sure what you mean ? >> All it says is what features should be supported. >> And the features that are write related have a small uppercase 1 next to >> them, indicating: >> "1 This feature is mandatory only when the Write bit of the DVD+RW Feature >> is set to one." >> >> So the presence of the plus R/W profiles does not guarantee the availability >> of features that deal with writing, only those that deal with reading. >> And hence no guarantee that commands such as "Read Disc Information" are >> supported, which you need to be able to recognize blank media. >> >> >> >>> Would it be correct then to say that a DVD-ROM that want to claim only >>> recognition of DVD+R/RW but *not* of additional commands has to list only >>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>> DVD+R/RW profile(s)? >>> >>> >> I think that a DVD-ROM drive that either does or doesn't support the +R/W >> profiles (and features) doesn't need to support the special commands that >> you need to determine blank media. >> >> >> >>> I still don't know actually if this would mean that blank DVD+R/RW media >>> are recognized or not. >>> >>> >> Bet on the fact that 99% of the ROM drives won't see blank media. >> And the availability of plus R/RW features and profiles is no indication nor >> guarantee that the drive can recognise blank media. >> >> >> >>> would it be correct to claim that devices claiming DVD+R/RW support have >>> to support blank DVD+R/RW also? >>> >>> >> No, only if they set the write bit to one. >> >> Best Regards, >> Peter >> ------------------------------------------------------- >> Peter Van Hove, CEO Smart Projects >> CD and DVD Data recovery >> Peter at Smart-Projects.net >> >> www.Smart-Projects.net >> www.IsoBuster.com >> ------------------------------------------------------- >> ----- Original Message ----- >> From: "David Burg" >> To: "Peter Van Hove" ; ; >> >> Sent: Tuesday, October 17, 2006 10:30 PM >> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> >> >> >>> Dear Peter, All, >>> >>> If I correctly understand your analysis, you analyzed the capabilities >>> claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted >>> for "This feature may be present only to represent additional capability >>> to the >>> DVD-ROM Profile. If the Write bit is set to zero, then no additional >>> capability is claimed.", is also said eventually "A device may report this >>> feature only when Profile 10h (DVD-ROM) is reported. No additional >>> commands or mode parameters are required." >>> >>> I am working on drives that reports the DVD+R/RW *profile*, not only the >>> feature. And in the profile definition, the additional commands support is >>> listed as mandatory. ("Drives identifying Profile 001Ah as current shall >>> support the features listed in Table 221.") >>> >>> Would it be correct then to say that a DVD-ROM that want to claim only >>> recognition of DVD+R/RW but *not* of additional commands has to list only >>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>> DVD+R/RW profile(s)? >>> >>> I still don't know actually if this would mean that blank DVD+R/RW media >>> are recognized or not. As the MMC specification does not make a >>> distinction in the support of DVD+R/RW between blank and recorded media, >>> would it be correct to claim that devices claiming DVD+R/RW support have >>> to support blank DVD+R/RW also? >>> >>> Best regards, >>> >>> David Burg, >>> Microsoft. >>> >>> -----Original Message----- >>> From: Peter Van Hove [mailto:Peter at Smart-Projects.net] >>> Sent: Monday, October 16, 2006 1:26 PM >>> To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org >>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> Dear David, All, >>> >>> I hope I'm not completely missing the point but >>> for DVD+R/W the way I understand it is the following. >>> >>> Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles >>> (and >>> hence also no features), then a modern drive will likely have no issues >>> with >>> DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs >>> and >>> blank media will likely not be seen as such. >>> >>> Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a >>> host must still request the relevant features to see if that drive is able >>> to write also in addition to reading the media. Since the ROM drive can't >>> write, the write bit will be set to zero. >>> All this means is a "guarantee" that +RW media is properly recognised, >>> nothing more. >>> MMC says: >>> "This feature may be present only to represent additional capability to >>> the >>> DVD-ROM Profile. If the Write bit is >>> set to zero, then no additional capability is claimed." >>> >>> I understand "then no additional capability is claimed." as compared to >>> the >>> DVD-ROM profile. >>> The DVD-ROM profile's "interesting" feature is the DVD Read feature. >>> The DVD read feature does not include the "READ DISC INFORMATION" command. >>> >>> In other words, a ROM drive that supports the DVD+ profiles and features, >>> but doesn't support the write bit to one, does no more than a DVD-ROM >>> drive >>> without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee >>> that DVD+R/W is supported *EVEN* when the booktype is still the original >>> booktype, and not the DVD-ROM booktype that is often used for >>> compatibility. >>> >>> I could be wrong, but this is how I understand it. >>> >>> PS., also from MMC (for the DVD+R feature for instance) >>> "If a Drive reports this feature with the Write bit set to one and the >>> Current bit set to one, then it shall support the >>> commands shown in table ..... " >>> >>> So only when the write bit is set to one additonal commands are supported, >>> including: >>> the "READ DISC INFORMATION" command >>> >>> >>> Best Regards, >>> Peter >>> ------------------------------------------------------- >>> Peter Van Hove >>> www.Smart-Projects.net >>> www.IsoBuster.com >>> ------------------------------------------------------- >>> ------------------------------------------------------- >>> ----- Original Message ----- >>> From: "David Burg" >>> To: >>> Cc: ; "Bhanu Gogineni" ; "Ahmed >>> Tolba" >>> Sent: Monday, October 16, 2006 8:10 PM >>> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> >>> >>> >>>> * From the T10 Reflector (t10 at t10.org), posted by: >>>> * David Burg >>>> * >>>> Hello Katata-san, >>>> >>>> Thank you for your answer. Your analysis is correct, in particular for CD >>>> and DVD dash where the said profile requests write features to be >>>> supported. But remains the particularity of the DVD plus command set, >>>> where the profile does not request write features to be supported unless >>>> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >>>> always mandatory, and this one includes the same READ DISC INFORMATION >>>> you >>>> mention. >>>> >>>> Best regards, >>>> >>>> David Burg. >>>> >>>> -----Original Message----- >>>> From: owner-mtfuji5 at avc-pioneer.com >>>> [mailto:owner-mtfuji5 at avc-pioneer.com] >>>> On Behalf Of keiji_katata at post.pioneer.co.jp >>>> Sent: Sunday, October 15, 2006 11:47 PM >>>> To: mtfuji5 at avc-pioneer.com >>>> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >>>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >>>> profiles >>>> >>>> >>>> Hi David, >>>> >>>> ----- Question ----- >>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>> drive >>>> mandate that it is capable of recognizing the matching blank R and/or >>>> RW/Rewritable profile? >>>> ------------------- >>>> I think it is yes. All commands listed in the Features those are listed >>>> in >>>> the >>>> Profile shall work correctly. So for example, CD-R profile requests >>>> "Incremental >>>> Streaming Writable Feature" and "CD Track at Once Feature". These >>>> Features >>>> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >>>> Those >>>> information must be reported from any condition of the CD-R disc except >>>> fatal >>>> error condition of the drive. I think Blank condition of CD-R is normal >>>> condition of the disc. >>>> >>>> On the other hand, these Feature request "This Feature identifies a Drive >>>> that >>>> is able to write data". Therefore ROM drive shall not report the >>>> supporting of >>>> there Features. Then ROM drive cannot report CD-R profile. >>>> >>>> Best regards, >>>> >>>> Keiji Katata >>>> PIONEER CORP. >>>> >>>> >>>> >>>> >>>> >>>> David Burg @avc-pioneer.com on 2006/10/14 >>>> 14:05:28 >>>> >>>> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J >>>> >>>> $BAw?.>>> >>>> >>>> >>>> >>>> $B08 at h(J: , >>>> cc: Bhanu Gogineni , Ahmed Tolba >>>> >>>> bcc: >>>> $B7oL>(J: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>> >>>> Hello, >>>> >>>> During validation of DVD-ROM devices conformance to the MMC command set >>>> through >>>> the Windows Vista Logo program and MMCTest tool, we were signaled the >>>> possible >>>> flaw in either our tool or the specification. Our tool query from the >>>> drive the >>>> list of profiles supported by the drive, and then exercises each of the >>>> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >>>> tool >>>> attempts to validate these profiles, and as part of the validation >>>> attempts to >>>> validate that the drive recognize blank media properly. >>>> >>>> Yes, blank media. I understand that hardware manufacturers may very well >>>> be >>>> reluctant to guarantee this capability on ROM drives. The value of >>>> recognizing >>>> blank media in a ROM drive that won$B!G(Jt be able to write it is also >>>> questionable. >>>> However there are also positives aspects: a ROM drive able to recognize >>>> the >>>> blank media will not spin un-definitively in attempt to find a track, it >>>> will >>>> further be capable to report that the media is blank to the host so that >>>> the >>>> host software may report the issue to the user and help him to correct >>>> his >>>> mistake. >>>> >>>> Clearly some ROM drives do not support recognizing blank recordable or >>>> rewritable media, even sometimes do not recognize recorded recordable or >>>> rewritable media. >>>> >>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>> drive >>>> mandate that it is capable of recognizing the matching blank R and/or >>>> RW/Rewritable profile? >>>> >>>> Best regards, >>>> >>>> David Burg, >>>> Microsoft Corporation. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> * >>>> * For T10 Reflector information, send a message with >>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>>> >>>> >>>> >>> >>> >> * >> * For T10 Reflector information, send a message with >> * 'info t10' (no quotes) in the message body to majordomo at t10.org >> >> >> >> > > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From billmc37 at ctesc.net Fri Oct 20 08:17:05 2006 From: billmc37 at ctesc.net (Bill McFerrin) Date: Fri, 20 Oct 2006 10:17:05 -0500 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Bill McFerrin * Dear David, I agree that it is not reasonable and I agree that poor wording (for which I am responsible) has probably caused some confusion, but given our weak definition of profile, it is permitted. Bill David Burg wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Ouch indeed, > > So you mean that a DVD-ROM drive shall never report the DVD+R/RW profiles? Because we at Microsoft have a failure in our tests precisely because of such DVD-ROM drives. > > Best regards, > > David Burg. > > -----Original Message----- > From: Bill McFerrin [mailto:billmc37 at ctesc.net] > Sent: Thursday, October 19, 2006 7:05 AM > To: David Burg > Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Ouch, > It gets worse. The paragraph below the DVD+RW Profile states that the > Write bit must be set to one. I will be posting rev 4 this weekend with > fixes based upon the ANSI editor's comments. The clarification here is > to remove the footnotes that cause confusion. > > Kind Regards, > Bill > > > David Burg wrote: > >> * From the T10 Reflector (t10 at t10.org), posted by: >> * David Burg >> * >> Hi Bill, >> >> You said: "Each DVD+ profile requires the ability to record." >> >> But the spec says in a note for the write features of the + profiles: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." >> >> Does DVD+ profile really require the ability to record? >> >> Best regards, >> >> David Burg. >> >> -----Original Message----- >> From: Bill McFerrin [mailto:billmc37 at ctesc.net] >> Sent: Wednesday, October 18, 2006 4:16 PM >> To: David Burg >> Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Hi David, >> There is less to this than you think. >> >> In the beginning (sort of), there was DVD-ROM and no writables. Some >> DVD-ROM drives rejected recorded DVD+RW discs (and sometimes others as >> well). We wanted a simple way for a DVD-ROM Drive to claim the ability >> to read recorded DVD+ discs. Each DVD+ feature followed that idea for >> consistency. >> >> Each DVD+ profile requires the ability to record. >> >> That's it. >> >> Kind Regards, >> Bill McFerrin >> >> David Burg wrote: >> >> >>> * From the T10 Reflector (t10 at t10.org), posted by: >>> * David Burg >>> * >>> Dear Peter, All, >>> >>> I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org >>> >>> Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." >>> >>> Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: >>> >>> "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." >>> >>> Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." >>> >>> Best regards, >>> >>> David Burg, >>> Microsoft. >>> >>> -----Original Message----- >>> From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove >>> Sent: Tuesday, October 17, 2006 2:19 PM >>> To: mtfuji5 at avc-pioneer.com; t10 at t10.org >>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> Dear David, All, >>> >>> >>> >>> >>>> If I correctly understand your analysis, you analyzed the capabilities >>>> claim from the DVD+R/W *feature(s)*. >>>> >>>> >>>> >>> I mentioned both, as both can only live together. If the plus profile is >>> reported the plus features will be present as well. >>> >>> >>> >>> >>>> "A device may report this feature only when Profile 10h (DVD-ROM) is >>>> reported" >>>> >>>> >>>> >>> Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. >>> I interpret that as, a drive must be a DVD ROM capable drive to be able to >>> do DVD+R/W. >>> >>> >>> >>> >>>> And in the profile definition, the additional commands support is listed >>>> as mandatory. ("Drives identifying Profile 001Ah as current shall support >>>> the features listed in Table 221.") >>>> >>>> >>>> >>> I'm not using the same rev as you do, as it's table 220 in my spec :) >>> But I'm not sure what you mean ? >>> All it says is what features should be supported. >>> And the features that are write related have a small uppercase 1 next to >>> them, indicating: >>> "1 This feature is mandatory only when the Write bit of the DVD+RW Feature >>> is set to one." >>> >>> So the presence of the plus R/W profiles does not guarantee the availability >>> of features that deal with writing, only those that deal with reading. >>> And hence no guarantee that commands such as "Read Disc Information" are >>> supported, which you need to be able to recognize blank media. >>> >>> >>> >>> >>>> Would it be correct then to say that a DVD-ROM that want to claim only >>>> recognition of DVD+R/RW but *not* of additional commands has to list only >>>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>>> DVD+R/RW profile(s)? >>>> >>>> >>>> >>> I think that a DVD-ROM drive that either does or doesn't support the +R/W >>> profiles (and features) doesn't need to support the special commands that >>> you need to determine blank media. >>> >>> >>> >>> >>>> I still don't know actually if this would mean that blank DVD+R/RW media >>>> are recognized or not. >>>> >>>> >>>> >>> Bet on the fact that 99% of the ROM drives won't see blank media. >>> And the availability of plus R/RW features and profiles is no indication nor >>> guarantee that the drive can recognise blank media. >>> >>> >>> >>> >>>> would it be correct to claim that devices claiming DVD+R/RW support have >>>> to support blank DVD+R/RW also? >>>> >>>> >>>> >>> No, only if they set the write bit to one. >>> >>> Best Regards, >>> Peter >>> ------------------------------------------------------- >>> Peter Van Hove, CEO Smart Projects >>> CD and DVD Data recovery >>> Peter at Smart-Projects.net >>> >>> www.Smart-Projects.net >>> www.IsoBuster.com >>> ------------------------------------------------------- >>> ----- Original Message ----- >>> From: "David Burg" >>> To: "Peter Van Hove" ; ; >>> >>> Sent: Tuesday, October 17, 2006 10:30 PM >>> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> >>> >>> >>> >>>> Dear Peter, All, >>>> >>>> If I correctly understand your analysis, you analyzed the capabilities >>>> claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted >>>> for "This feature may be present only to represent additional capability >>>> to the >>>> DVD-ROM Profile. If the Write bit is set to zero, then no additional >>>> capability is claimed.", is also said eventually "A device may report this >>>> feature only when Profile 10h (DVD-ROM) is reported. No additional >>>> commands or mode parameters are required." >>>> >>>> I am working on drives that reports the DVD+R/RW *profile*, not only the >>>> feature. And in the profile definition, the additional commands support is >>>> listed as mandatory. ("Drives identifying Profile 001Ah as current shall >>>> support the features listed in Table 221.") >>>> >>>> Would it be correct then to say that a DVD-ROM that want to claim only >>>> recognition of DVD+R/RW but *not* of additional commands has to list only >>>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>>> DVD+R/RW profile(s)? >>>> >>>> I still don't know actually if this would mean that blank DVD+R/RW media >>>> are recognized or not. As the MMC specification does not make a >>>> distinction in the support of DVD+R/RW between blank and recorded media, >>>> would it be correct to claim that devices claiming DVD+R/RW support have >>>> to support blank DVD+R/RW also? >>>> >>>> Best regards, >>>> >>>> David Burg, >>>> Microsoft. >>>> >>>> -----Original Message----- >>>> From: Peter Van Hove [mailto:Peter at Smart-Projects.net] >>>> Sent: Monday, October 16, 2006 1:26 PM >>>> To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org >>>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>> >>>> Dear David, All, >>>> >>>> I hope I'm not completely missing the point but >>>> for DVD+R/W the way I understand it is the following. >>>> >>>> Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles >>>> (and >>>> hence also no features), then a modern drive will likely have no issues >>>> with >>>> DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs >>>> and >>>> blank media will likely not be seen as such. >>>> >>>> Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a >>>> host must still request the relevant features to see if that drive is able >>>> to write also in addition to reading the media. Since the ROM drive can't >>>> write, the write bit will be set to zero. >>>> All this means is a "guarantee" that +RW media is properly recognised, >>>> nothing more. >>>> MMC says: >>>> "This feature may be present only to represent additional capability to >>>> the >>>> DVD-ROM Profile. If the Write bit is >>>> set to zero, then no additional capability is claimed." >>>> >>>> I understand "then no additional capability is claimed." as compared to >>>> the >>>> DVD-ROM profile. >>>> The DVD-ROM profile's "interesting" feature is the DVD Read feature. >>>> The DVD read feature does not include the "READ DISC INFORMATION" command. >>>> >>>> In other words, a ROM drive that supports the DVD+ profiles and features, >>>> but doesn't support the write bit to one, does no more than a DVD-ROM >>>> drive >>>> without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee >>>> that DVD+R/W is supported *EVEN* when the booktype is still the original >>>> booktype, and not the DVD-ROM booktype that is often used for >>>> compatibility. >>>> >>>> I could be wrong, but this is how I understand it. >>>> >>>> PS., also from MMC (for the DVD+R feature for instance) >>>> "If a Drive reports this feature with the Write bit set to one and the >>>> Current bit set to one, then it shall support the >>>> commands shown in table ..... " >>>> >>>> So only when the write bit is set to one additonal commands are supported, >>>> including: >>>> the "READ DISC INFORMATION" command >>>> >>>> >>>> Best Regards, >>>> Peter >>>> ------------------------------------------------------- >>>> Peter Van Hove >>>> www.Smart-Projects.net >>>> www.IsoBuster.com >>>> ------------------------------------------------------- >>>> ------------------------------------------------------- >>>> ----- Original Message ----- >>>> From: "David Burg" >>>> To: >>>> Cc: ; "Bhanu Gogineni" ; "Ahmed >>>> Tolba" >>>> Sent: Monday, October 16, 2006 8:10 PM >>>> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>> >>>> >>>> >>>> >>>> >>>>> * From the T10 Reflector (t10 at t10.org), posted by: >>>>> * David Burg >>>>> * >>>>> Hello Katata-san, >>>>> >>>>> Thank you for your answer. Your analysis is correct, in particular for CD >>>>> and DVD dash where the said profile requests write features to be >>>>> supported. But remains the particularity of the DVD plus command set, >>>>> where the profile does not request write features to be supported unless >>>>> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >>>>> always mandatory, and this one includes the same READ DISC INFORMATION >>>>> you >>>>> mention. >>>>> >>>>> Best regards, >>>>> >>>>> David Burg. >>>>> >>>>> -----Original Message----- >>>>> From: owner-mtfuji5 at avc-pioneer.com >>>>> [mailto:owner-mtfuji5 at avc-pioneer.com] >>>>> On Behalf Of keiji_katata at post.pioneer.co.jp >>>>> Sent: Sunday, October 15, 2006 11:47 PM >>>>> To: mtfuji5 at avc-pioneer.com >>>>> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >>>>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >>>>> profiles >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> ----- Question ----- >>>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>>> drive >>>>> mandate that it is capable of recognizing the matching blank R and/or >>>>> RW/Rewritable profile? >>>>> ------------------- >>>>> I think it is yes. All commands listed in the Features those are listed >>>>> in >>>>> the >>>>> Profile shall work correctly. So for example, CD-R profile requests >>>>> "Incremental >>>>> Streaming Writable Feature" and "CD Track at Once Feature". These >>>>> Features >>>>> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >>>>> Those >>>>> information must be reported from any condition of the CD-R disc except >>>>> fatal >>>>> error condition of the drive. I think Blank condition of CD-R is normal >>>>> condition of the disc. >>>>> >>>>> On the other hand, these Feature request "This Feature identifies a Drive >>>>> that >>>>> is able to write data". Therefore ROM drive shall not report the >>>>> supporting of >>>>> there Features. Then ROM drive cannot report CD-R profile. >>>>> >>>>> Best regards, >>>>> >>>>> Keiji Katata >>>>> PIONEER CORP. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> David Burg @avc-pioneer.com on 2006/10/14 >>>>> 14:05:28 >>>>> >>>>> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B >>>>> >>>>> $BAw?.>>>> >>>>> >>>>> >>>>> >>>>> $B08 at h(B: , >>>>> cc: Bhanu Gogineni , Ahmed Tolba >>>>> >>>>> bcc: >>>>> $B7oL>(B: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>>> >>>>> Hello, >>>>> >>>>> During validation of DVD-ROM devices conformance to the MMC command set >>>>> through >>>>> the Windows Vista Logo program and MMCTest tool, we were signaled the >>>>> possible >>>>> flaw in either our tool or the specification. Our tool query from the >>>>> drive the >>>>> list of profiles supported by the drive, and then exercises each of the >>>>> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >>>>> tool >>>>> attempts to validate these profiles, and as part of the validation >>>>> attempts to >>>>> validate that the drive recognize blank media properly. >>>>> >>>>> Yes, blank media. I understand that hardware manufacturers may very well >>>>> be >>>>> reluctant to guarantee this capability on ROM drives. The value of >>>>> recognizing >>>>> blank media in a ROM drive that won$B!G(Bt be able to write it is also >>>>> questionable. >>>>> However there are also positives aspects: a ROM drive able to recognize >>>>> the >>>>> blank media will not spin un-definitively in attempt to find a track, it >>>>> will >>>>> further be capable to report that the media is blank to the host so that >>>>> the >>>>> host software may report the issue to the user and help him to correct >>>>> his >>>>> mistake. >>>>> >>>>> Clearly some ROM drives do not support recognizing blank recordable or >>>>> rewritable media, even sometimes do not recognize recorded recordable or >>>>> rewritable media. >>>>> >>>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>>> drive >>>>> mandate that it is capable of recognizing the matching blank R and/or >>>>> RW/Rewritable profile? >>>>> >>>>> Best regards, >>>>> >>>>> David Burg, >>>>> Microsoft Corporation. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> * >>>>> * For T10 Reflector information, send a message with >>>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> * >>> * For T10 Reflector information, send a message with >>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>> >>> >>> >>> >>> >> >> * >> * For T10 Reflector information, send a message with >> * 'info t10' (no quotes) in the message body to majordomo at t10.org >> >> >> >> > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From t10 at RichRamos.com Fri Oct 20 15:01:05 2006 From: t10 at RichRamos.com (Rich Ramos) Date: Fri, 20 Oct 2006 15:01:05 -0700 Subject: SPC-4: question on SERVICE ACTION IN/OUT Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Rich Ramos * Hey guys, I have a question regarding SERVICE ACTION IN/OUT 12 and 16. I noticed that 06-223r1 brought a vendor specific service action into MAINTENANCE IN/OUT and was wondering if there was any proposal/plan to do the same thing for SERVICE ACTION IN/OUT 12 and 16? Right now 1Fh is restricted but I'm not clear if that's because it's used somewhere else? If so where? If not why's it restricted? Thanks, Rich * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Sat Oct 21 23:03:33 2006 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 22 Oct 2006 00:03:33 -0600 Subject: Recent T10 documents uploaded since 2006/10/15 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SAS-2 Modifications to the SAS Speed Negotiation (by: Stephen Finch, Amr Wassal) T10/06-324r6 Uploaded: 2006/10/19 329026 bytes ftp://ftp.t10.org/t10/document.06/06-324r6.pdf SSC-3 Encryption KAD Lengths, Nonces, and Resets (by: Paul Suhler) T10/06-412r1 Uploaded: 2006/10/20 12375 bytes ftp://ftp.t10.org/t10/document.06/06-412r1.pdf Minutes of SAS PHY Working Group teleconference Nov 12, 2006 (by: Alvin Cox) T10/06-457r0 Uploaded: 2006/10/17 20118 bytes ftp://ftp.t10.org/t10/document.06/06-457r0.pdf T11 Liaison Report, October, 2006 (by: Robert Snively) T10/06-458r0 Uploaded: 2006/10/16 11299 bytes ftp://ftp.t10.org/t10/document.06/06-458r0.pdf SAS-2 Broadcast after count update (by: Luben Tuikov) T10/06-459r0 Uploaded: 2006/10/17 20378 bytes ftp://ftp.t10.org/t10/document.06/06-459r0.pdf SAM-4 Time bounds of task states (by: Luben Tuikov) T10/06-460r0 Uploaded: 2006/10/18 30028 bytes ftp://ftp.t10.org/t10/document.06/06-460r0.pdf SAM-4 Time bounds of task states (by: Luben Tuikov) T10/06-460r1 Uploaded: 2006/10/19 36489 bytes ftp://ftp.t10.org/t10/document.06/06-460r1.pdf SAM-4 Time bounds of task states (by: Luben Tuikov) T10/06-460r2 Uploaded: 2006/10/20 37928 bytes ftp://ftp.t10.org/t10/document.06/06-460r2.pdf Minutes of SAS PHY Working Group teleconference Nov 19, 2006 (by: Alvin Cox) T10/06-461r0 Uploaded: 2006/10/19 22123 bytes ftp://ftp.t10.org/t10/document.06/06-461r0.pdf SSC-3 Keyless Copy of Encrypted Data (by: Kevin Butt) T10/06-462r0 Uploaded: 2006/10/20 32017 bytes ftp://ftp.t10.org/t10/document.06/06-462r0.pdf Working Drafts -------------- (Report generated on 2006/10/22 at 00:03:31) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From daviburg at windows.microsoft.com Mon Oct 23 23:05:33 2006 From: daviburg at windows.microsoft.com (David Burg) Date: Mon, 23 Oct 2006 23:05:33 -0700 Subject: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * David Burg * Well, maybe we can address the problem. Our test has the ability to report warnings for things which are not right but which we have to tolerate (likely for everything before rev 4). Would it be a correct test to warn if a DVD+R/RW profile is listed although no write bit is set in the matching DVD+R/RW feature? Also, if you fix the specification, we can restore the test, and grant an exception for adaptation duration (e.g. 6 to 12 months). During the exception time, a pass will be granted to devices failing this test. This allow hardware manufacturer to correct the problem before the test is enforced. Sometime this means the correction is made in the next drive generation, among other improvements. Best regards, David Burg. -----Original Message----- From: Bill McFerrin [mailto:billmc37 at ctesc.net] Sent: Friday, October 20, 2006 8:17 AM To: David Burg Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles Dear David, I agree that it is not reasonable and I agree that poor wording (for which I am responsible) has probably caused some confusion, but given our weak definition of profile, it is permitted. Bill David Burg wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * David Burg > * > Ouch indeed, > > So you mean that a DVD-ROM drive shall never report the DVD+R/RW profiles? Because we at Microsoft have a failure in our tests precisely because of such DVD-ROM drives. > > Best regards, > > David Burg. > > -----Original Message----- > From: Bill McFerrin [mailto:billmc37 at ctesc.net] > Sent: Thursday, October 19, 2006 7:05 AM > To: David Burg > Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org > Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles > > Ouch, > It gets worse. The paragraph below the DVD+RW Profile states that the > Write bit must be set to one. I will be posting rev 4 this weekend with > fixes based upon the ANSI editor's comments. The clarification here is > to remove the footnotes that cause confusion. > > Kind Regards, > Bill > > > David Burg wrote: > >> * From the T10 Reflector (t10 at t10.org), posted by: >> * David Burg >> * >> Hi Bill, >> >> You said: "Each DVD+ profile requires the ability to record." >> >> But the spec says in a note for the write features of the + profiles: "1 This feature is mandatory only when the Write bit of the DVD+RW Feature is set to one." >> >> Does DVD+ profile really require the ability to record? >> >> Best regards, >> >> David Burg. >> >> -----Original Message----- >> From: Bill McFerrin [mailto:billmc37 at ctesc.net] >> Sent: Wednesday, October 18, 2006 4:16 PM >> To: David Burg >> Cc: mtfuji5 at avc-pioneer.com; t10 at t10.org >> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >> >> Hi David, >> There is less to this than you think. >> >> In the beginning (sort of), there was DVD-ROM and no writables. Some >> DVD-ROM drives rejected recorded DVD+RW discs (and sometimes others as >> well). We wanted a simple way for a DVD-ROM Drive to claim the ability >> to read recorded DVD+ discs. Each DVD+ feature followed that idea for >> consistency. >> >> Each DVD+ profile requires the ability to record. >> >> That's it. >> >> Kind Regards, >> Bill McFerrin >> >> David Burg wrote: >> >> >>> * From the T10 Reflector (t10 at t10.org), posted by: >>> * David Burg >>> * >>> Dear Peter, All, >>> >>> I am reading mmc5r03c.pdf. This is the latest MMC 5 document on www.t10.org >>> >>> Thank you Peter for the clarification. However something does not add up: there is a delta between the DVD-ROM profile mandatory features and the DVD+RW profile mandatory features, not only write features (20h and 23h), and DVD+RW feature (2Ah), but also DCBs (10Ah). This is more than DVD-ROM capabilities so I question that the spec sentence "If the Write bit is set to zero, then no additional capability is claimed." really means not additional capability but DVD-ROM read is claimed. I think it means instead, no additional capability than claim until here in this feature definition. Likely referring to the feature introduction "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]." >>> >>> Now we could approach the problem differently than splitting hairs and trying to second-guess the meaning of the sentences, and try instead to specify what is the actual drives on market behavior. You say that most ROM drives won't see blank and +R/RW features and profiles don't change that. Maybe we need a clarification sentence in the specification of the +R/RW features, rewording the introductions sentences: >>> >>> "The presence of the DVD+RW Feature indicates that the Drive is capable of reading a recorded DVD+RW disc that is formatted according to [DVD+Ref2]. Recognition of blank DVD+RW disc is guaranteed only if the write bit of this feature is set to one." >>> >>> Btw, there is an inconsistency between the RW and the R feature specification wording. Only the R feature says "Specifically, this includes the capability of reading DCBs." >>> >>> Best regards, >>> >>> David Burg, >>> Microsoft. >>> >>> -----Original Message----- >>> From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Peter Van Hove >>> Sent: Tuesday, October 17, 2006 2:19 PM >>> To: mtfuji5 at avc-pioneer.com; t10 at t10.org >>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> Dear David, All, >>> >>> >>> >>> >>>> If I correctly understand your analysis, you analyzed the capabilities >>>> claim from the DVD+R/W *feature(s)*. >>>> >>>> >>>> >>> I mentioned both, as both can only live together. If the plus profile is >>> reported the plus features will be present as well. >>> >>> >>> >>> >>>> "A device may report this feature only when Profile 10h (DVD-ROM) is >>>> reported" >>>> >>>> >>>> >>> Yes, as in, a drive that can't read DVDs can also not read DVD+R/W discs. >>> I interpret that as, a drive must be a DVD ROM capable drive to be able to >>> do DVD+R/W. >>> >>> >>> >>> >>>> And in the profile definition, the additional commands support is listed >>>> as mandatory. ("Drives identifying Profile 001Ah as current shall support >>>> the features listed in Table 221.") >>>> >>>> >>>> >>> I'm not using the same rev as you do, as it's table 220 in my spec :) >>> But I'm not sure what you mean ? >>> All it says is what features should be supported. >>> And the features that are write related have a small uppercase 1 next to >>> them, indicating: >>> "1 This feature is mandatory only when the Write bit of the DVD+RW Feature >>> is set to one." >>> >>> So the presence of the plus R/W profiles does not guarantee the availability >>> of features that deal with writing, only those that deal with reading. >>> And hence no guarantee that commands such as "Read Disc Information" are >>> supported, which you need to be able to recognize blank media. >>> >>> >>> >>> >>>> Would it be correct then to say that a DVD-ROM that want to claim only >>>> recognition of DVD+R/RW but *not* of additional commands has to list only >>>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>>> DVD+R/RW profile(s)? >>>> >>>> >>>> >>> I think that a DVD-ROM drive that either does or doesn't support the +R/W >>> profiles (and features) doesn't need to support the special commands that >>> you need to determine blank media. >>> >>> >>> >>> >>>> I still don't know actually if this would mean that blank DVD+R/RW media >>>> are recognized or not. >>>> >>>> >>>> >>> Bet on the fact that 99% of the ROM drives won't see blank media. >>> And the availability of plus R/RW features and profiles is no indication nor >>> guarantee that the drive can recognise blank media. >>> >>> >>> >>> >>>> would it be correct to claim that devices claiming DVD+R/RW support have >>>> to support blank DVD+R/RW also? >>>> >>>> >>>> >>> No, only if they set the write bit to one. >>> >>> Best Regards, >>> Peter >>> ------------------------------------------------------- >>> Peter Van Hove, CEO Smart Projects >>> CD and DVD Data recovery >>> Peter at Smart-Projects.net >>> >>> www.Smart-Projects.net >>> www.IsoBuster.com >>> ------------------------------------------------------- >>> ----- Original Message ----- >>> From: "David Burg" >>> To: "Peter Van Hove" ; ; >>> >>> Sent: Tuesday, October 17, 2006 10:30 PM >>> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>> >>> >>> >>> >>> >>>> Dear Peter, All, >>>> >>>> If I correctly understand your analysis, you analyzed the capabilities >>>> claim from the DVD+R/W *feature(s)*. And in the paragraph which you quoted >>>> for "This feature may be present only to represent additional capability >>>> to the >>>> DVD-ROM Profile. If the Write bit is set to zero, then no additional >>>> capability is claimed.", is also said eventually "A device may report this >>>> feature only when Profile 10h (DVD-ROM) is reported. No additional >>>> commands or mode parameters are required." >>>> >>>> I am working on drives that reports the DVD+R/RW *profile*, not only the >>>> feature. And in the profile definition, the additional commands support is >>>> listed as mandatory. ("Drives identifying Profile 001Ah as current shall >>>> support the features listed in Table 221.") >>>> >>>> Would it be correct then to say that a DVD-ROM that want to claim only >>>> recognition of DVD+R/RW but *not* of additional commands has to list only >>>> the DVD-ROM profile and the DVD+R/RW feature(s) but *not* list the >>>> DVD+R/RW profile(s)? >>>> >>>> I still don't know actually if this would mean that blank DVD+R/RW media >>>> are recognized or not. As the MMC specification does not make a >>>> distinction in the support of DVD+R/RW between blank and recorded media, >>>> would it be correct to claim that devices claiming DVD+R/RW support have >>>> to support blank DVD+R/RW also? >>>> >>>> Best regards, >>>> >>>> David Burg, >>>> Microsoft. >>>> >>>> -----Original Message----- >>>> From: Peter Van Hove [mailto:Peter at Smart-Projects.net] >>>> Sent: Monday, October 16, 2006 1:26 PM >>>> To: David Burg; mtfuji5 at avc-pioneer.com; t10 at t10.org >>>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>> >>>> Dear David, All, >>>> >>>> I hope I'm not completely missing the point but >>>> for DVD+R/W the way I understand it is the following. >>>> >>>> Suppose a DVD-ROM drive doesn't report any of the DVD+ (plus) profiles >>>> (and >>>> hence also no features), then a modern drive will likely have no issues >>>> with >>>> DVD+R/W discs but will not recognise them as such, only as DVD-ROM discs >>>> and >>>> blank media will likely not be seen as such. >>>> >>>> Suppose a DVD-ROM drive that DOES report the DVD+ profiles then indeed a >>>> host must still request the relevant features to see if that drive is able >>>> to write also in addition to reading the media. Since the ROM drive can't >>>> write, the write bit will be set to zero. >>>> All this means is a "guarantee" that +RW media is properly recognised, >>>> nothing more. >>>> MMC says: >>>> "This feature may be present only to represent additional capability to >>>> the >>>> DVD-ROM Profile. If the Write bit is >>>> set to zero, then no additional capability is claimed." >>>> >>>> I understand "then no additional capability is claimed." as compared to >>>> the >>>> DVD-ROM profile. >>>> The DVD-ROM profile's "interesting" feature is the DVD Read feature. >>>> The DVD read feature does not include the "READ DISC INFORMATION" command. >>>> >>>> In other words, a ROM drive that supports the DVD+ profiles and features, >>>> but doesn't support the write bit to one, does no more than a DVD-ROM >>>> drive >>>> without the DVD+ profiles and features, EXCEPT maybe that it's a guarantee >>>> that DVD+R/W is supported *EVEN* when the booktype is still the original >>>> booktype, and not the DVD-ROM booktype that is often used for >>>> compatibility. >>>> >>>> I could be wrong, but this is how I understand it. >>>> >>>> PS., also from MMC (for the DVD+R feature for instance) >>>> "If a Drive reports this feature with the Write bit set to one and the >>>> Current bit set to one, then it shall support the >>>> commands shown in table ..... " >>>> >>>> So only when the write bit is set to one additonal commands are supported, >>>> including: >>>> the "READ DISC INFORMATION" command >>>> >>>> >>>> Best Regards, >>>> Peter >>>> ------------------------------------------------------- >>>> Peter Van Hove >>>> www.Smart-Projects.net >>>> www.IsoBuster.com >>>> ------------------------------------------------------- >>>> ------------------------------------------------------- >>>> ----- Original Message ----- >>>> From: "David Burg" >>>> To: >>>> Cc: ; "Bhanu Gogineni" ; "Ahmed >>>> Tolba" >>>> Sent: Monday, October 16, 2006 8:10 PM >>>> Subject: RE: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>> >>>> >>>> >>>> >>>> >>>>> * From the T10 Reflector (t10 at t10.org), posted by: >>>>> * David Burg >>>>> * >>>>> Hello Katata-san, >>>>> >>>>> Thank you for your answer. Your analysis is correct, in particular for CD >>>>> and DVD dash where the said profile requests write features to be >>>>> supported. But remains the particularity of the DVD plus command set, >>>>> where the profile does not request write features to be supported unless >>>>> the write bit of the DVD+R/RW feature is one. Still, DVD Read feature is >>>>> always mandatory, and this one includes the same READ DISC INFORMATION >>>>> you >>>>> mention. >>>>> >>>>> Best regards, >>>>> >>>>> David Burg. >>>>> >>>>> -----Original Message----- >>>>> From: owner-mtfuji5 at avc-pioneer.com >>>>> [mailto:owner-mtfuji5 at avc-pioneer.com] >>>>> On Behalf Of keiji_katata at post.pioneer.co.jp >>>>> Sent: Sunday, October 15, 2006 11:47 PM >>>>> To: mtfuji5 at avc-pioneer.com >>>>> Cc: t10 at t10.org; Bhanu Gogineni; Ahmed Tolba >>>>> Subject: Re: MMC/Mt Fuji: Clarification about R and RW/Rewritable >>>>> profiles >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> ----- Question ----- >>>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>>> drive >>>>> mandate that it is capable of recognizing the matching blank R and/or >>>>> RW/Rewritable profile? >>>>> ------------------- >>>>> I think it is yes. All commands listed in the Features those are listed >>>>> in >>>>> the >>>>> Profile shall work correctly. So for example, CD-R profile requests >>>>> "Incremental >>>>> Streaming Writable Feature" and "CD Track at Once Feature". These >>>>> Features >>>>> request READ DISC INFORMATION command and READ TRACK INFORMATION command. >>>>> Those >>>>> information must be reported from any condition of the CD-R disc except >>>>> fatal >>>>> error condition of the drive. I think Blank condition of CD-R is normal >>>>> condition of the disc. >>>>> >>>>> On the other hand, these Feature request "This Feature identifies a Drive >>>>> that >>>>> is able to write data". Therefore ROM drive shall not report the >>>>> supporting of >>>>> there Features. Then ROM drive cannot report CD-R profile. >>>>> >>>>> Best regards, >>>>> >>>>> Keiji Katata >>>>> PIONEER CORP. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> David Burg @avc-pioneer.com on 2006/10/14 >>>>> 14:05:28 >>>>> >>>>> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J >>>>> >>>>> $BAw?.>>>> >>>>> >>>>> >>>>> >>>>> $B08 at h(J: , >>>>> cc: Bhanu Gogineni , Ahmed Tolba >>>>> >>>>> bcc: >>>>> $B7oL>(J: MMC/Mt Fuji: Clarification about R and RW/Rewritable profiles >>>>> >>>>> Hello, >>>>> >>>>> During validation of DVD-ROM devices conformance to the MMC command set >>>>> through >>>>> the Windows Vista Logo program and MMCTest tool, we were signaled the >>>>> possible >>>>> flaw in either our tool or the specification. Our tool query from the >>>>> drive the >>>>> list of profiles supported by the drive, and then exercises each of the >>>>> profiles. Some ROM drives will also report R and/or RW profiles. Thus our >>>>> tool >>>>> attempts to validate these profiles, and as part of the validation >>>>> attempts to >>>>> validate that the drive recognize blank media properly. >>>>> >>>>> Yes, blank media. I understand that hardware manufacturers may very well >>>>> be >>>>> reluctant to guarantee this capability on ROM drives. The value of >>>>> recognizing >>>>> blank media in a ROM drive that won$B!G(Jt be able to write it is also >>>>> questionable. >>>>> However there are also positives aspects: a ROM drive able to recognize >>>>> the >>>>> blank media will not spin un-definitively in attempt to find a track, it >>>>> will >>>>> further be capable to report that the media is blank to the host so that >>>>> the >>>>> host software may report the issue to the user and help him to correct >>>>> his >>>>> mistake. >>>>> >>>>> Clearly some ROM drives do not support recognizing blank recordable or >>>>> rewritable media, even sometimes do not recognize recorded recordable or >>>>> rewritable media. >>>>> >>>>> So the question is: Does reporting R and/or RW/Rewritable profile by a >>>>> drive >>>>> mandate that it is capable of recognizing the matching blank R and/or >>>>> RW/Rewritable profile? >>>>> >>>>> Best regards, >>>>> >>>>> David Burg, >>>>> Microsoft Corporation. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> * >>>>> * For T10 Reflector information, send a message with >>>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> * >>> * For T10 Reflector information, send a message with >>> * 'info t10' (no quotes) in the message body to majordomo at t10.org >>> >>> >>> >>> >>> >> >> * >> * For T10 Reflector information, send a message with >> * 'info t10' (no quotes) in the message body to majordomo at t10.org >> >> >> >> > > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From steve.finch at st.com Tue Oct 24 09:18:59 2006 From: steve.finch at st.com (Stephen FINCH) Date: Tue, 24 Oct 2006 10:18:59 -0600 Subject: SAS-2: Notify Power Loss Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Stephen FINCH * Section 7.2.5.10.3 states: "If a SAS target device supports NOTIFY (POWER LOSS EXPECTED) and receives NOTIFY (POWER LOSS EXPECTED) on an SSP target port, then each SAS phy within the target device shall: a) if there is an SSP connection, then transmit a BREAK on that connection; and b) respond to SSP connection requests with OPEN_REJECT (RETRY) until the power loss timeout timer expires or power is lost. If any frames are received by the SAS target device after receiving NOTIFY (POWER LOSS EXPECTED) before a connection is closed, then the SAS target device shall discard the received frames." Since it is the CC state machine that transmits BREAK primitives, I looked to that state machine to see where and how this is accomplished. There is no inputs to that state machine indicating the reception of a NOTIFY (POWER LOSS EXPECTED). That being the case, I thought maybe the SSP state machine had an input for the NOTIFY (POWER LOSS EXPECTED) and, in turn, would issue a Request Break to the CC state machine. SURPRISE! SURPRISE! The SSP state machine doesn't have such an input either. And there is no input to the SSP state machine from higher levels that can generate a BREAK. SO, how are NOTIFY (POWER LOSS EXPECTED) supposed to be handled? I think we need state machine changes in the Link Layer to handle the requirements above, or we need to remove the requirements. Regards, Steve Finch STMicroelectronics 303 381-3587 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From gop at us.ibm.com Tue Oct 24 10:58:51 2006 From: gop at us.ibm.com (George Penokie) Date: Tue, 24 Oct 2006 12:58:51 -0500 Subject: SAS-2: Notify Power Loss Message-ID: Formatted message: HTML-formatted message Steve, Yes, I am aware of that as Mark pointed it out to me last week. He sent me a note with some suggestions on how it should be handled. I plan on putting a fix into my 06-451 proposal. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 Stephen FINCH 10/24/2006 11:18 AM To "T10 Reflector" , George Penokie/Rochester/IBM at IBMUS cc Subject SAS-2: Notify Power Loss Section 7.2.5.10.3 states: "If a SAS target device supports NOTIFY (POWER LOSS EXPECTED) and receives NOTIFY (POWER LOSS EXPECTED) on an SSP target port, then each SAS phy within the target device shall: a) if there is an SSP connection, then transmit a BREAK on that connection; and b) respond to SSP connection requests with OPEN_REJECT (RETRY) until the power loss timeout timer expires or power is lost. If any frames are received by the SAS target device after receiving NOTIFY (POWER LOSS EXPECTED) before a connection is closed, then the SAS target device shall discard the received frames." Since it is the CC state machine that transmits BREAK primitives, I looked to that state machine to see where and how this is accomplished. There is no inputs to that state machine indicating the reception of a NOTIFY (POWER LOSS EXPECTED). That being the case, I thought maybe the SSP state machine had an input for the NOTIFY (POWER LOSS EXPECTED) and, in turn, would issue a Request Break to the CC state machine. SURPRISE! SURPRISE! The SSP state machine doesn't have such an input either. And there is no input to the SSP state machine from higher levels that can generate a BREAK. SO, how are NOTIFY (POWER LOSS EXPECTED) supposed to be handled? I think we need state machine changes in the Link Layer to handle the requirements above, or we need to remove the requirements. Regards, Steve Finch STMicroelectronics 303 381-3587 From Alvin.Cox at seagate.com Tue Oct 24 12:34:22 2006 From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com) Date: Tue, 24 Oct 2006 14:34:22 -0500 Subject: SAS PHY call on 10/26 Message-ID: Formatted message: HTML-formatted message The following proposal will be on the agenda this week. Please review before the call. It has to do with OOB at 1,5 Gbps only for SAS-2. >From a pure specification perspective, SAS phy's that do not support being attached to SATA are not required to recognize an OOB signal burst that consists of a D24.3 pattern at 1,5 Gbps. It would be helpful for all silicon and device suppliers to review their sAS 1.1 OOB detector designs and determine if this proposal will cause any compatibility problems (do existing phy's OOB detectors work with a D24.3 character OOB signal) http://www.t10.org/ftp/t10/document.06/06-463r0.pdf Alvin Cox Seagate Technology, LLC Tel 405-350-7424 Cell 405-206-4809 From Alvin.Cox at seagate.com Wed Oct 25 11:24:54 2006 From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com) Date: Wed, 25 Oct 2006 13:24:54 -0500 Subject: Reminder: SAS PHY working group teleconference Oct 26 10 am Central / 8 am Pacific Message-ID: Formatted message: HTML-formatted message PARTICIPANT INFORMATION: Toll Free Dial in Number: (866) 279-4742 International Access/Caller Paid Dial In Number: (309) 229-0118 PARTICIPANT CODE: 3243413 Webex information: https://seagate.webex.com/seagate Topic: SAS-2 PHY WG Date: Thursday, Oct 26, 2006 Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) Meeting number: 826 515 680 Meeting password: 6gbpsSAS Agenda: 1. SAS-2 COMWAKE detection requirements [Cox] http://www.t10.org/ftp/t10/document.06/06-464r0.pdf 2. SAS-2 OOB transmission requirements [Cox] http://www.t10.org/ftp/t10/document.06/06-463r0.pdf 3. New items. 4. SAS-2 Modifications to the SAS Speed Negotiation http://www.t10.org/ftp/t10/document.06/06-324r6.pdf Alvin Cox Seagate Technology, LLC Tel 405-350-7424 Cell 405-206-4809 From roger_cummings at symantec.com Wed Oct 25 16:02:19 2006 From: roger_cummings at symantec.com (Roger Cummings) Date: Wed, 25 Oct 2006 19:02:19 -0400 Subject: An alternative proposal from SNIA Message-ID: Formatted message: HTML-formatted message Folks, As you may remember, I had a proposal (06-392r0) posted for the September CAP meeting that was not presented at the meeting because of a lack of time. 06-392r0 requested that a range of values in the Security Protocols field of the SECURITY PROTOCOLS IN and SECURITY PROTOCOLS OUT commands be designated as "Defined by the SNIA" for the purpose of providing a method of transporting one of the protocols associated with the DMTF Common Information Model (CIM) across a SCSI infrastructure. CIM is the basis of SNIA's Storage Management Interface (SMI-S), the first generation of which has been published as ANSI/INCITS 388-2004. Although 392r0 was not formally presented at the CAP meeting, a number of people privately expressed the opinion that they would prefer that a separate pair of MANAGEMENT IN and MANAGEMENT OUT commands be defined for the purpose of transporting CIM and other management-related protocols over a SCSI infrastructure. The SNIA Management Protocols Tech Working Group (MP TWG) discussed that idea, determined that it would meet their requirements, and as a result I was directed to produce an alternative proposal to T10 to define those commands. I uploaded that proposal yesterday as 06-465r0. I've also posted a minor revision to the previous proposal, to correct some typos add a further background paragraph, and genericize the requested value range, and that revision was also uploaded yesterday as 06-392r1. Both 392r1 and 465r0 are on the agenda for the upcoming CAP meeting. To further emphasize the above, the approach defined in either document is acceptable to SNIA, and so the decision on which to proceed with is for T10. Please review both proposals, let me know of any required corrections or clarifications, and come to the next CAP meeting prepared to choose an approach. Regards, Roger Cummings SYMANTEC roger_cummings at symantec.com (on behalf of the SNIA MP TWG) From roweber at ieee.org Thu Oct 26 11:41:22 2006 From: roweber at ieee.org (Ralph Weber) Date: Thu, 26 Oct 2006 13:41:22 -0500 Subject: SPC-4: question on SERVICE ACTION IN/OUT Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Ralph Weber * Rich, The SERVICE ACTION IN/OUT table for 12 byte CDBs was added in SPC-3 revision 10 (November 2002). It was added in anticipation of the READ MEDIA SERIAL NUMBER command, which remains the only command listed in the table. In SPC-3 revision 10 SERVICE ACTION OUT service action 1Fh was Reserved. In SPC-3 revision 13 (May 2003), it was changed to Restricted. All available evidence indicates that the change was made in response to SPC-3 editing meetings held on 6 and 8 May, for which no minutes were taken. Since the change is in an informative annex, it is a priori editorial and therefore no formal vote is (or was) needed to make it. As the Restricted keyword definition states, Restricted means SPC-x does not and will not define the meaning of the 1Fh service action. "3.3.10 Restricted: A keyword referring to bits, bytes, words, and fields that are set aside for use in other SCSI standards. A restricted bit, byte, word, or field shall be treated as a reserved bit, byte, word or field for the purposes of the requirements defined in this standard." From my point of view, the purpose of Restricted is to allow other SCSI command sets to operate freely without having to modify SPC-x for every command definition they develop. For this reason, I have no clue regarding where SERVICE ACTION OUT(12) service action 1Fh is used. It may be used in several command set standards. It may be used in none. I suspect (but cannot prove) that the May 2003 editing meeting marked the 1Fh service action as Restricted to allow for its use in any command set with no particular use identified. The SERVICE ACTION IN/OUT tables have remained as you see them in SPC-4 r07a from May 2003 to this day. I am aware of no efforts to change them. However, I have not conducted a concerted inspection of the upcoming CAP agenda pursuant to preparing this message. All the best, .Ralph Rich Ramos wrote: > * From the T10 Reflector (t10 at t10.org), posted by: > * Rich Ramos > * > > Hey guys, > > I have a question regarding SERVICE ACTION IN/OUT 12 and 16. I > noticed that 06-223r1 brought a vendor specific service action into > MAINTENANCE IN/OUT and was wondering if there was any proposal/plan to > do the same thing for SERVICE ACTION IN/OUT 12 and 16? Right now 1Fh > is restricted but I'm not clear if that's because it's used somewhere > else? If so where? If not why's it restricted? > > Thanks, > Rich > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo at t10.org > > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From gop at us.ibm.com Thu Oct 26 13:23:50 2006 From: gop at us.ibm.com (George Penokie) Date: Thu, 26 Oct 2006 15:23:50 -0500 Subject: Fw: T10 Document Number Assigned (T10/06-451r1) Message-ID: Formatted message: HTML-formatted message The 06-451r1 proposal has been posted. Along with the fixes in rev 0, it contains the changes to all the state machines to accommodate the NOTIFY (Power Loss Expected). It effects the link layer, port layer, transport layer, and SCSI application layer. In addition it requires changes to SAM-4. Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop at us.ibm.com Internal: 553-5208 External: 507-253-5208 ----- Forwarded by George Penokie/Rochester/IBM on 10/26/2006 03:15 PM ----- T10 Document Administrator Sent by: 10/26/2006 03:10 PM To George Penokie/Rochester/IBM at IBMUS cc Subject Re: Re: T10 Document Number Assigned (T10/06-451r1) 2006/10/26 14:10:43 Your request to upload a file or files to the T10 site has been accepted. Your PDF file will be posted at: http://www.t10.org/ftp/t10/document.06/06-451r1.pdf Normally, the posting/archiving process takes about 30 minutes. Please contact John Lohmeyer should you need further assistance. George Penokie wrote: > To: T10 Document Administrator > Subject: Re: T10 Document Number Assigned (T10/06-451r1) > From: George Penokie > Date: Thu, 26 Oct 2006 14:56:23 -0500 > Extracted-To: AutoPost > > > >
Bye for now,
> George Penokie
>
> Dept 9A8 030-3 A410
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208 >
>
>
> > >
T10 Document Administrator > >
Sent by: >

10/26/2006 02:54 PM >

> > > > >
>
To
> 		George Penokie/Rochester/IBM at IBMUS >
>
cc
> 		>
>
Subject
> 		T10 Document Number Assigned (T10/06-451r1)
>
> > >
>
>
>
>
>
2006/10/26 13:54:04 (AD v1.30)
>
> ## Your T10 document number request has been approved and
> ## the following document number was assigned:
>
>  Document Number: T10/06-451r1
>      Upload Code: AC_02486zat1meWedh (Do not delete or > change this line.)
>    Document_Date: 2006/10/26
>  Document_Author: George O. Penokie
>   Document_Title: SAS-2: SAM-4: Miscellaneous State Machine Fixes
>   Meeting_Agenda: SAS_Prot - Serial Attached SCSI Protocol
> Document_Comments:
>     Other_Number:
>
> ## POSTING YOUR DOCUMENT USING A WEB BROWSER
> ## -----------------------------------------
> ##
> ## You may upload the file(s) for your document using
> ## the form at:
> ##
> ##   http://www.t10.org/fupload.htm ##
> ##
> ## POSTING YOUR DOCUMENT BY REPLYING TO THIS EMAIL
> ## -----------------------------------------------
> ##
> ## Please reply to this email and attach your document to the
> ## reply email.  Please attach both the source file and a PDF
> ## file made from your source file.  The source file may be
> ## ZIP'd, but the PDF file must not be ZIP'd.
> ##
> ## Please generate your PDF files for posting to be compatible
> ## with Acrobat 4.0 (PDF 1.3). (This parameter is set in
> ## Distiller, Settings, Job Options, Compatibility.)
> ##
> ## If you do not attach a PDF file, your upload will be
> ## forwarded to an administrator.  This will delay your
> ## posting until the administrator can make the PDF file
> ## for you.
> ##
> ## While you are not required to provide the source file, it is
> ## strongly recommended that you do so.  The source file
> ## will be archived in case the PDF file must be re-created.
> ##
> ## It is critical that your reply email include the above
> ## Upload Code.  Without it, your posting cannot be processed.
> ## The filenames you use for your attachment(s) are not important
> ## as long as the extensions are correct.
> ##
> ##
> ## POSTING NON-PDF DOCUMENTS
> ## -------------------------
> ##
> ## A PDF file is necessary for the T10 mailings. You may also
> ## post one or more non-PDF files on the T10 web site as long as
> ## the extensions are all unique. These files are not included
> ## in the T10 mailings, but are made available for downloading.
> ##
> ## To post additional files on the T10 web site, edit the
> ## Post_File line to add the file extension(s) that you want
> ## posted. Then attach file(s) with matching extensions to your
> ## email.
> ##
> ## Example: To post an Excel spreadsheet in addition to a PDF
> ## file, edit the line to read: Post_File: PDF XLS
> ##
> Post_File: PDF
> ##
> ## Any files you attach that do not match an extension listed
> ## on the Post_File line will be assumed to be a source file
> ## and will be archived but not posted.
> ##
> ##
> ##  CHANGING YOUR MIND
> ##  ------------------
> ##
> ## If you wish to cancel this document number, reply to this email
> ## without any attachments and edit the following line to change
> ## the word no to yes:
> ##
>   Cancel_Document_Number: no
> ##
> ## Once you post a document, you cannot cancel it.
> ##
> ##
> ##  EDITING DOCUMENT INFORMATION
> ##  ----------------------------
> ##
> ## If one of the above fields Document Date, Document Title,
> ## Document Author, Document Title, Meeting Agenda, Comments,
> ## and Other Number is no longer accurate, you may edit it as
> ## necessary.
> ##
> ## Be careful if you edit the Meeting Agenda field; only the first
> ## word is used.  It must be one of the words available on the
> ## Add_to_agenda pull-down from the web site.  These words may
> ## change periodically and as of June 2002 they were: ADI, CAP, MMC,
> ## PIP, SAS_Prot, SAS_PHY, SBP, SPI, SRP, SSC, SSM, and T10.
> ##
> ##
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## Do not submit documents containing a copyright statement
> ## unless you add the following statement:
> ##
> ##    Permission is granted to members of INCITS, its technical
> ##    committees and their associated task groups to reproduce
> ##    this document for the purposes of INCITS standardization
> ##    activities, provided this notice is included.
> ##
> ## If you upload a copyrighted document, with or without
> ## this statement, it will be assumed implicitly that you
> ## and your organization have given the above permission.
> ##
> ##
> ## APPROPRIATE CONTENT
> ## -------------------
> ##
> ## Do not upload inappropriate material.  If you do, your
> ## files will be removed and your posting privileges will
> ## be revoked.
>
> >
> > > Attachment Converted: "C:\ATTACH\06-451r1.pdf" From kade.soprano at texmemsys.com Fri Oct 27 11:53:35 2006 From: kade.soprano at texmemsys.com (Kade Soprano) Date: Fri, 27 Oct 2006 13:53:35 -0500 Subject: No subject Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Kade Soprano * Sir/Madam, I am writing in regards to a question that I have about the WRITE BUFFER SCSI command. In particular, my question pertains to the data sent from the application client for the echo buffer mode (0AH). The specification (SPC-3) states that "Data shall be sent aligned on four-byte boundaries." Does this mean that the device server should check that the data is aligned on four-byte boundaries and terminate the command with a CHECK CONDITION status if the data isn't aligned properly, or, to be a little less harsh, properly align [down] the data if it isn't? This is what I gather from my reading of the specifications, but since it's not explicitly stated, I cannot be sure. Thank you for your time. Kade M. Soprano * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Gerry.Houlder at seagate.com Fri Oct 27 13:43:58 2006 From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com) Date: Fri, 27 Oct 2006 15:43:58 -0500 Subject: Write Buffer question Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Gerry.Houlder at seagate.com * The boundary alignment normally checked by verifying the Buffer Offset field. Since this is ignored for Echo Buffer option the target will assume that zero is the intended value for this field. Zero is a "4 byte aligned" value. The only way the target would notice a descrepancy is if the Transfer Length was not a multiple of 4. Even this may not be seen as an error since the standard doesn't require a multiple of 4 bytes have to be sent. Typical usage is to use a 256 byte pattern on each command. Kade Soprano To Sent by: t10 at t10.org owner-t10 at t10.org cc No Phone Info Available Subject 10/27/2006 01:53 PM * From the T10 Reflector (t10 at t10.org), posted by: * Kade Soprano * Sir/Madam, I am writing in regards to a question that I have about the WRITE BUFFER SCSI command. In particular, my question pertains to the data sent from the application client for the echo buffer mode (0AH). The specification (SPC-3) states that "Data shall be sent aligned on four-byte boundaries." Does this mean that the device server should check that the data is aligned on four-byte boundaries and terminate the command with a CHECK CONDITION status if the data isn't aligned properly, or, to be a little less harsh, properly align [down] the data if it isn't? This is what I gather from my reading of the specifications, but since it's not explicitly stated, I cannot be sure. Thank you for your time. Kade M. Soprano * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Sat Oct 28 23:03:43 2006 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 29 Oct 2006 00:03:43 -0600 Subject: Recent T10 documents uploaded since 2006/10/22 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SSC-3: Cleaning Model (by: Kevin Butt) T10/05-285r0 Uploaded: 2006/10/25 45126 bytes ftp://ftp.t10.org/t10/document.05/05-285r0.pdf SAS-2 Multiplexing (by: Rob Elliott) T10/05-381r6 Uploaded: 2006/10/23 802301 bytes ftp://ftp.t10.org/t10/document.05/05-381r6.pdf SSC: Configurable EW (by: Kevin Butt) T10/05-423r3 Uploaded: 2006/10/24 33535 bytes ftp://ftp.t10.org/t10/document.05/05-423r3.pdf SAS-2 Support multiple STP affiliations (by: Rob Elliott) T10/06-188r2 Uploaded: 2006/10/24 80466 bytes ftp://ftp.t10.org/t10/document.06/06-188r2.pdf SAS-2 ALIGN insertion rate during STP connections (by: Rob Elliott) T10/06-275r0 Uploaded: 2006/10/27 110942 bytes ftp://ftp.t10.org/t10/document.06/06-275r0.pdf SAM-4 SPC-4 WRITE BUFFER clarifications (by: Rob Elliott) T10/06-282r3 Uploaded: 2006/10/24 108675 bytes ftp://ftp.t10.org/t10/document.06/06-282r3.pdf SAS-2 SNW-3 bit definitions (by: Rob Elliott) T10/06-363r3 Uploaded: 2006/10/28 125636 bytes ftp://ftp.t10.org/t10/document.06/06-363r3.pdf Proposal for Management Transport (by: Roger Cummings) T10/06-392r1 Uploaded: 2006/10/24 194315 bytes ftp://ftp.t10.org/t10/document.06/06-392r1.pdf On-disk bitmap support (by: Roger Cummings) T10/06-393r1 Uploaded: 2006/10/24 221603 bytes ftp://ftp.t10.org/t10/document.06/06-393r1.pdf Results of Letter Ballot on forwarding ADC-2 to first public review (by: John Lohmeyer) T10/06-447r0 Uploaded: 2006/10/25 435116 bytes ftp://ftp.t10.org/t10/document.06/06-447r0.pdf Results of Letter Ballot on forwarding ADC-2 to first public review (by: John Lohmeyer) T10/06-447r0 Uploaded: 2006/10/25 181402 bytes ftp://ftp.t10.org/t10/document.06/06-447r0.txt SAS-2: SAM-4: Miscellaneous State Machine Fixes (by: George O. Penokie) T10/06-451r1 Uploaded: 2006/10/26 458722 bytes ftp://ftp.t10.org/t10/document.06/06-451r1.pdf SAS-2 OOB transmission requirements (by: Alvin Cox) T10/06-463r0 Uploaded: 2006/10/24 52768 bytes ftp://ftp.t10.org/t10/document.06/06-463r0.pdf SAS-2 COMWAKE detection requirements (by: Alvin Cox) T10/06-464r0 Uploaded: 2006/10/25 23287 bytes ftp://ftp.t10.org/t10/document.06/06-464r0.pdf Alternative Proposal for Management Transport (by: Roger Cummings) T10/06-465r0 Uploaded: 2006/10/24 190621 bytes ftp://ftp.t10.org/t10/document.06/06-465r0.pdf SAS-2 OPEN_REJECT RETRY during self-configuration changes (by: Rob Elliott) T10/06-466r0 Uploaded: 2006/10/26 46342 bytes ftp://ftp.t10.org/t10/document.06/06-466r0.pdf Initiator handling of retransmit read DATA frames (by: Vicky Duerk/Bob Sheffield) T10/06-467r0 Uploaded: 2006/10/27 23795 bytes ftp://ftp.t10.org/t10/document.06/06-467r0.pdf ADC-2: NL-Port vs. LN-Port (by: Kevin Butt) T10/06-468r0 Uploaded: 2006/10/25 34175 bytes ftp://ftp.t10.org/t10/document.06/06-468r0.pdf SAS-2: Transport layer read data flowchart (by: George O. Penokie) T10/06-470r0 Uploaded: 2006/10/27 105422 bytes ftp://ftp.t10.org/t10/document.06/06-470r0.pdf SAS-2 Change to phy reset sequence 10ms rule (by: Brian Day) T10/06-471r0 Uploaded: 2006/10/27 67572 bytes ftp://ftp.t10.org/t10/document.06/06-471r0.pdf SAS-2 REPORT EXPANDER ROUTE TABLE descriptor layout change (by: Rob Elliott) T10/06-473r0 Uploaded: 2006/10/27 17046 bytes ftp://ftp.t10.org/t10/document.06/06-473r0.pdf SAS-2 Broadcast (Zone Activate) only by ZONED BROADCAST (by: Rob Elliott) T10/06-474r0 Uploaded: 2006/10/28 76451 bytes ftp://ftp.t10.org/t10/document.06/06-474r0.pdf Working Drafts -------------- MultiMedia Command Set - 5 (MMC-5) (Editor: Bill McFerrin) Rev: 04 Uploaded: 2006/10/24 4262533 bytes ftp://ftp.t10.org/t10/drafts/mmc5/mmc5r04.pdf (Report generated on 2006/10/29 at 00:03:41) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From keiji_katata at post.pioneer.co.jp Mon Oct 30 03:18:10 2006 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Mon, 30 Oct 2006 20:18:10 +0900 Subject: Consideration of 2/4/7, 2/4/8 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I put documents about Consideration of 2/4/7, 2/4/8. Please pick up and study them. ftp.avc-pioneer.com/Mtfuji_7/Proposal/Nov06/Pioneer/247-248/ Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org