Write Protection Model
keiji_katata at post.pioneer.co.jp
keiji_katata at post.pioneer.co.jp
Tue Dec 21 18:28:49 PST 1999
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
Hello Ai san,
About class 1 event, we can make it mandatory if logical unit supports
class 1 event. So I would like to change the sentence, "If logical unit
supports class 1 event reporting, logical unit shall generate class 1
About Feature, I would like to introduce new idea that is partially
persistent Feature. In this idea, reporting is persistent, but setting is
option and in sometime it is available, in other it is not available. I
agree that this is different with current Feature and Current bit
definition. Other way is "adding the RWP (Reporting Write Protection
status) bit into core feature". Write Protection feature shows PWP setting
ability (this is Tokumitsu san's opinion).
Which is better?
reply to aiai at dsd.mei.co.jp
to: Keiji Katata/Pioneer
cc: mtfuji2 at dt.wdc.com, mmc at dt.wdc.com, t10 at t10.org
subject: Re: Write Protection Model
---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
> Pioneer's write protection proposals.
> Here are Matsushita's comments and counter proposal regarding
> Protection Model.
> 1) MECHANISM STATUS command
> - In the Mt.Fuji3 specification, no information regarding a type
> other property of a medium in each slot is in the Slot Table
> format. The purpose of this command is to obtain an information of
> current situation of a "Slot" not a disc. It means that a property of
> medium shall be maintained by Host not Logical Unit. So we think
> extension in your proposal is not needed.
> 2) Event Reporting
> - According to you proposal, Logical Unit shall generate Class 1
> when the Write Protection status is changed. But my understanding is
> the Class 1 Event is generated when the Logical Unit's behavior
> changed by for example changing its microcode. But the Write
> status is based on the disc not the Logical Unit. Even if the PWP bit
> changed to one by a command, no Feature is added and no Microcode
> changed. So we think the Class 1 is not appropriate.
> - Our counter proposal is to generate Class 4 Event instead of Class
> 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
> is that the function which is specified by the Feature is "supported"
> the Logical Unit regardless of the function is currently executable
> not. In your proposals, the Feature indicates that the Logical Unit
> report the write protection status.
> It means if the READ DVD STRUCTURE command with Format code C0h
> "supported" by a Logical Unit, this Feature shall be reported
> of the command is executable or not.
> - The Current bit shall be set to one when the functionality indicated
> the Feature is currently executable. According to Pioneer's proposal,
> Write Protection Feature indicates to support the functionality to
> the Write Protection status of the medium though READ DVD
> command with Format code C0h. When a media is inserted, this command
> executable I think. So the Current bit is set to one when a
> medium is mounted.
> - This is to clarify, but does the SWPW bit is set to one if the
> Unit "support" the READ DVD STRUCTURE command with Format code C0h
> when the mounted medium is write protected by the write protect tab
> the cartridge?
> Best Regards,
> Takaharu Ai
> Osaka, Japan
> About "1) MECHANISM STATUS command", so I remove PWP from the Slot
> Response format. The CWP in the Slot Table Response format
> "Partial Medium Load for MAM Access" like functionality. Some device
> 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
> class 1 event, not class 4 event. 2nd reason is reporting class 4
> may confuse the system. Usually the system which supports writing on
> media by particular file system shall supports reading the media and
> used file system. There is no advantage useing class 4.
My understanding is that the Write Protection Status change Event is same
When an unformatted DVD-RAM medium is mounted in the Logical Unit, the
Readable and Random Writable Features with Current bit set to zero are
the medium is formatted, these Features become Current.
This is the same situation as the Write Protection status change. When a
Write Protected 4.7GB DVD-RAM medium is mounted in the Logical Unit, the
Writable and Formattable Features with Current bit set to zero are
returned. If the
medium is write permitted through SEND DVD STRUCTURE command, these
According to the Mt.Fuji3 document, the Class 1 event is applied to inform
medium has been formatted. But the Class 1 Event itself is not mandatory
Formattable Feature. I think some of devices does not implement Class 1
it is still Mt.Fuji3 Compliant device. Changing of Write Protection status
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
(e.g. all of Write protections are cleared or one of them is set to
Features that allows erasing/formatting/writing on media are changed, the
Unit may generate Class 1 Events.
> About "3) Write Protection Feature", I may not understand the all
> of this comment. But it may be as follows. Reading write
> status and Setting write protection status shall be separated same
> "Random Readable Feature" & "Random Writeable Feature". But it
> redundant, it is too much for such a write protection issue, I think.
> no media status or ROM media in the device is defined as write
> status because any write shall be failed, reading write protection
> can be "Persistent". But in December meeting, we decided that
> media, Read DVD Structure command with format code C0h shall
> terminated with Check Condition. Then it is not Persistent.
> However, there is no need to use current bit to show "you can see
> write protection status now". Because if media is installed, you can
> the write protection status that is defined by the media
I am sorry for my unclear explanation.
I meant your proposal had an inconsistency about the definition of the
the Current bit.
<<from the definition of the Feature>>
According to your proposal, the Write Protect Feature indicates a Logical
an ability to report the write protect status by READ DVD STRUCTURE command
Format code C0h. This means that the Current bit of this feature shall be
one when the ability to report the write protect status is active, i.e.
READ DVD STRUCTURE command with Format code C0h can be executed normally,
Feature shall be Current.
<<from the definition of the Current bit>>
According to your proposal, the definition of the Current bit is that the
be set to zero if the Logical Unit can not set/release the PWP status on
mounted media surface. This means the Write Protect Feature shall indicate
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
should be changed to as follows,
Current bit shall be defined as in Table 109-Feature Descriptor generic
page 228. This bit shall be set to one if the Logical Unit can report
protect status on the mounted medium surface through READ DVD STRUCTURE
with Format code C0h.
* 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