Write Protection Model

Takaharu Ai aiai at dsd.mei.co.jp
Tue Dec 21 17:36:03 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <aiai at dsd.mei.co.jp>
*
Hi Katata-san,


---Start of the original message ------------------------------------
>From: keiji_katata at post.pioneer.co.jp
>Date: Mon, 20 Dec 1999 14:02:08 +0900
>To: aiai at dsd.mei.co.jp
>Cc: mtfuji2 at dt.wdc.com, mmc at dt.wdc.com, t10 at t10.org
>Subject: Re: Write Protection Model
>

>
>  Takaharu Ai, <aiai at dsd.mei.co.jp> wrote:-------------------
>
>  Dear Kohda-san,
>
>  I  ams  sorry  for  late  responce  but  we  have some comments regarding
>  Pioneer's write protection proposals.
>
>  Here  are  Matsushita's  comments  and  counter  proposal regarding Write
>  Protection Model.
>
>  1) MECHANISM STATUS command
>  -  In  the  Mt.Fuji3  specification,  no information regarding a type and
>  other  property  of  a  medium in each slot is in the Slot Table Response
>  format.  The  purpose  of this command is to obtain an information of the
>  current  situation  of a "Slot" not a disc. It means that a property of a
>  medium  shall  be  maintained  by  Host not Logical Unit. So we think the
>  extension in your proposal is not needed.
>
>  2) Event Reporting
>  -  According  to  you proposal, Logical Unit shall generate Class 1 Event
>  when the Write Protection status is changed. But my understanding is that
>  the  Class  1  Event  is  generated  when  the Logical Unit's behavior is
>  changed  by  for example changing its microcode. But the Write Protection
>  status is based on the disc not  the Logical Unit. Even if the PWP bit is
>  changed  to  one  by  a  command, no Feature is added and no Microcode is
>  changed. So we think the Class 1 is not appropriate.
>  -  Our  counter  proposal is to generate Class 4 Event instead of Class 1
>  Event. Because the changing of PWP is very similar to change medium.
>
>  3) Write Protection Feature
>  - The meaning that Feature which is returned by GET CONFIGURATION command
>  is  that the function which is specified by the Feature is "supported" by
>  the  Logical  Unit  regardless of the function is currently executable or
>  not.  In  your proposals, the Feature indicates that the Logical Unit can
>  report the write protection status.
>  It  means  if  the  READ  DVD  STRUCTURE  command with Format code C0h is
>  "supported"  by a Logical Unit, this Feature shall be reported regardless
>  of the command is executable or not.
>  - The Current bit shall be set to one when the functionality indicated by
>  the Feature is currently executable. According to Pioneer's proposal, the
>  Write Protection Feature indicates to support the functionality to report
>  the  Write  Protection  status  of  the  medium though READ DVD STRUCTURE
>  command  with  Format code C0h. When a media is inserted, this command is
>  executable  I  think.  So  the  Current bit is set to one when a writable
>  medium is mounted.
>  -  This is to clarify, but does the SWPW bit is set to one if the Logical
>  Unit  "support"  the READ DVD STRUCTURE command with Format code C0h even
>  when  the  mounted  medium is write protected by the write protect tab on
>  the cartridge?
>
>  Best Regards,
>
>  Takaharu Ai
>  SDBD/AVC/MEI
>  Osaka, Japan
>  ------------------------------
>  About  "1) MECHANISM STATUS command", so I remove PWP from the Slot Table
>  Response  format.  The  CWP  in  the  Slot Table Response format provides
>  "Partial  Medium Load for MAM Access" like functionality. Some device can
>  read CWP status without loading the cartridge into its play position.

I understand the intention of your proposal. I agree with you.


>
>  About  "2) Event Reporting", I disagree completely. 1st reason is this is
>  class  1  event, not class 4 event. 2nd reason is reporting class 4 event
>  may  confuse the system. Usually the system which supports writing on the
>  media  by particular file system shall supports reading the media and the
>  used file system. There is no advantage useing class 4.

My understanding is that the Write Protection Status change Event is same as 
Formatting.

When an unformatted DVD-RAM medium is mounted in the Logical Unit, the Random 
Readable and Random Writable Features with Current bit set to zero are returned. If 
the medium is formatted, these Features become Current.

This is the same situation as the Write Protection status change. When a Persistent 
Write Protected 4.7GB DVD-RAM medium is mounted in the Logical Unit, the Random 
Writable and Formattable Features with Current bit set to zero are returned. If the 
medium is write permitted through SEND DVD STRUCTURE command, these Features become 
Current.

According to the Mt.Fuji3 document, the Class 1 event is applied to inform that 
medium has been formatted. But the Class 1 Event itself is not mandatory for 
Formattable Feature. I think some of devices does not implement Class 1 Event and 
it is still Mt.Fuji3 Compliant device. Changing of Write Protection status should be 
the same as Formatting. Generation of Class 1 Event shall not be mandatory.

So I would like to change my proposal to as follows,

  8.4 Event Reporting
  When Write Protection status of mounted medium and/or Logical Unit is changed 
  (e.g. all of Write protections are cleared or one of them is set to active), any 
  Features that allows erasing/formatting/writing on media are changed, the Logical 
  Unit may generate Class 1 Events.


>  About "3) Write Protection Feature", I may not understand the all meaning
>  of  this  comment.  But  it  may  be as follows. Reading write protection
>  status  and  Setting  write  protection status shall be separated same as
>  "Random  Readable  Feature"  &  "Random  Writeable  Feature".  But  it is
>  redundant,  it is too much for such a write protection issue, I think. If
>  no  media status or ROM media in the device is defined as write protected
>  status because any write shall be failed, reading write protection status
>  can  be  "Persistent".  But  in December meeting, we decided that without
>  media,  Read  DVD  Structure  command  with  format  code  C0h  shall  be
>  terminated with Check Condition. Then it is not Persistent.
>  However,  there  is  no  need to use current bit to show "you can see the
>  write  protection status now". Because if media is installed, you can see
>  the  write  protection  status that is defined by the media specification
>  always.

I am sorry for my unclear explanation.
I meant your proposal had an inconsistency about the definition of the Feature and 
the Current bit.

<<from the definition of the Feature>>
According to your proposal, the Write Protect Feature indicates a Logical Unit has 
an ability to report the write protect status by READ DVD STRUCTURE command with 
Format code C0h. This means that the Current bit of this feature shall be set to 
one when the ability to report the write protect status is active, i.e. when the 
READ DVD STRUCTURE command with Format code C0h can be executed normally, this 
Feature shall be Current.

<<from the definition of the Current bit>>
According to your proposal, the definition of the Current bit is that the bit shall 
be set to zero if the Logical Unit can not set/release the PWP status on the 
mounted media surface. This means the Write Protect Feature shall indicate a 
Logical Unit has an ability to change PWP status of the media.

The meaning of my original proposal was that the definition of the Current bit 
should be changed to as follows,

  Current bit shall be defined as in Table 109-Feature Descriptor generic format on 
  page 228. This bit shall be set to one if the Logical Unit can report write 
  protect status on the mounted medium surface through READ DVD STRUCTURE command 
  with Format code C0h.


Best Regards,


Takaharu Ai
SDBD/AVC/MEI
Osaka, Japan
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list